Futures should never block the thread
leo60228 opened this issue · comments
Currently, the Sink and Stream implementations lock a parking_lot::Mutex, which will park the thread. This will almost always cause a deadlock.
The futures-intrusive crate can wrap any lock_api Mutex (including parking_lot) to solve this, but it doesn't provide a blocking way to lock it. I don't see any reason this isn't possible, though, so you could open an issue.
futures-intrusive seems cool. I will look into it.
please try to use the following with try spins only
futures_multiqueue_with(<capacity>,<try_spins>,<yield_spins>)
if you are suffering from a dead lock. although I didn't see why hybrid lock will cause a problem.
I am not very sure about your question about
The futures-intrusive crate can wrap any lock_api Mutex (including parking_lot) to solve this, but it doesn't provide a blocking way to lock it.
It is using MutexLockFuture which is using Mutex, and a queue called ListNode
| pub fn lock(&self) -> GenericMutexLockFuture<'_, MutexType, T> {
| GenericMutexLockFuture::<MutexType, T> {
| mutex: Some(&self),
| wait_node: ListNode::new(WaitQueueEntry::new()),
| }
| }
It is not unavoidable but with a park queue as the final resort could save from forever busy waiting.