Document possible Mutex deadlock in block_in_place#7899
Document possible Mutex deadlock in block_in_place#7899fuzzypixelz wants to merge 1 commit intotokio-rs:masterfrom
Mutex deadlock in block_in_place#7899Conversation
|
Rendered: 
All links are valid. I found the MRE too complicated to include in the Rustdoc string, so I linked the issue instead. I couldn't find any existing instances where documentation links to closed issues so I don't know how appropriate this is. cc @Darksonn. |
| /// Be aware that although this function avoids starving other independently | ||
| /// spawned tasks, any other code running concurrently in the same task will | ||
| /// be suspended during the call to `block_in_place`. This can happen e.g. | ||
| /// when using the [`join!`] macro. To avoid this issue, use | ||
| /// [`spawn_blocking`] instead of `block_in_place`. |
There was a problem hiding this comment.
We already have this paragraph.
The issue is not really specific to Mutex. It happens with lots of stuff, but you make it sound like the only problem is Mutex. If you want to write something that talks about Mutex, it needs to be clear that it's an example and that it applies to any other code running in the same task.
There was a problem hiding this comment.
We already have this paragraph.
I understand that the two paragraphs are perhaps too similar, my intension was for the added paragraph to have the extra context of block_on use. I don't mind merging the second paragraph into the first, I'm just not yet sure if spawn_blocking is a good workaround for this issue as well (if it actually does solve it at all?).
The issue is not really specific to Mutex. It happens with lots of stuff, but you make it sound like the only problem is Mutex.
Right, it seems to me that it happens with Semaphore and RwLock as well. Is there a concept that encompasses all/most possible cases? In either case, I agree Mutex should be marked as an example.
I'll rework this once I have satisfactory answers to both questions.> We already have this paragraph.
I understand that the two paragraphs are perhaps too similar, my intension was for the added paragraph to have the extra context of block_on use. I don't mind merging the second paragraph into the first, I'm just not yet sure if spawn_blocking is a good workaround for this issue as well (if it actually does solve it at all?).
The issue is not really specific to Mutex. It happens with lots of stuff, but you make it sound like the only problem is Mutex.
Right, it seems to me that it happens with Semaphore and RwLock as well. Is there a concept that encompasses all/most possible cases? In either case, I agree Mutex should be marked as an example.
I'll rework this once I have satisfactory answers to both questions.
There was a problem hiding this comment.
I'm just not yet sure if
spawn_blockingis a good workaround for this issue as well
The most generic thing I can say is "to avoid this, do not use block_in_place". There does not exist one single alternative I can recommend that works in all cases.
I recommend spawn_blocking, which is sometimes a suitable alternative, but it's not identical to block_in_place and so it does not work in all cases where block_in_place can be used.
Is there a concept that encompasses all/most possible cases?
The way I would describe the general problem is "intra-task concurrency". That is to say, the task calling block_in_place is also running any other future concurrently within the same task, using any intra-task concurrency primitive such as select!, join!, FuturesUnordered, buffer_unordered, etc
The bug is a variation of what has been recently dubbed futurelock.
mattiapitossi
added
T-docs
3 participants
Resolves #7892.