For Krabby (my very-very-WIP Rust compiler), I did find a sensible use case for my parallel name resolver; a query on thread A ("look up core::iter::Iterator") can depend on a query being processed by thread B ("parse core/iter.rs"). Small atomics + a concurrent hash table lets me detect such conflicts, but I don't want to block the thread when this happens (parsing can take a while); instead, the hash table lets thread A pass on its work to thread B, to execute when its query finishes. Thread A will simply report "the query would block, come back later" and move on to other stuff. Once thread B is done, it will re-enqueue the blocked work. I'm excited to implement this, it's going to be so cool!
For Krabby (my very-very-WIP Rust compiler), I did find a sensible use case for my parallel name resolver; a query on thread A ("look up core::iter::Iterator") can depend on a query being processed by thread B ("parse core/iter.rs"). Small atomics + a concurrent hash table lets me detect such conflicts, but I don't want to block the thread when this happens (parsing can take a while); instead, the hash table lets thread A pass on its work to thread B, to execute when its query finishes. Thread A will simply report "the query would block, come back later" and move on to other stuff. Once thread B is done, it will re-enqueue the blocked work. I'm excited to implement this, it's going to be so cool!