Skip to content

Commit 2d76909

Browse files
committed
Update changelog
1 parent 3d9962e commit 2d76909

1 file changed

Lines changed: 11 additions & 0 deletions

File tree

CHANGELOG.md

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -5,6 +5,17 @@ All notable changes to this project will be documented in this file.
55
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
66
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
77

8+
## [Unreleased]
9+
* Potential fix for #3 (long running futures eventually stall):
10+
* Background:
11+
* Turns out this is likely related to ALL executor queues used by this crate (`crossbeam-queue`, `heapless MPMC`) being incompatible with OSes spawning threads at different priorities (since these queues do not use the OS mutexes, they are amenable to priority inversion issues - https://github.com/crossbeam-rs/crossbeam/issues/675#issuecomment-4003522816)
12+
* Note that very likely [`async-executor`](https://github.com/smol-rs/async-executor) is also affected, as it uses `concurrent-queue`, which has the same issue
13+
* For more tetails, check https://github.com/esp-rs/esp-idf-svc/issues/630
14+
* Solution:
15+
* Use our own queue based on a mutex + `alloc::VeqDeque` (unbounded) or `heapless::Deque` (bounded)
16+
* Since the queue is now protected by a mutex (via `embassy-sync`) - as long as the mutex is the OS/Platform one - and it is by default - there should be no priority inversion issues anymore
17+
* Furter, allow the user to plug her own executor queue, via the new `ExecutorQueue` trait
18+
819
## [0.4.1] - 2023-11-09
920
* Update to heapless 0.8, and use heapless `MpMcQueue` for targets that do not have atomics, as `crossbeam` does not support such targets yet
1021

0 commit comments

Comments
 (0)