Comment by dwroberts
7 hours ago
Would be interested to know what people think of the locking implementation for the net worker pool.
I’m no expert but it seems like a strange choice to me - using a mutex around an MPSC receiver, so whoever locks first gets to block until they get a message.
Is that not introducing unnecessary contention? It wouldn’t be that hard to just retain a sender for each worker and just round robin them
I haven’t looked at the code, but what you’re describing doesn’t sound that bad. If the queue is empty then it doesn’t matter whether a worker is waiting on the lock or waiting on the receiver itself. If the queue is non-empty then whoever has the lock will soon complete the receive and release the lock. It would be better to just use an actual MPMC channel, but if the traffic on the queue isn’t too high then it probably doesn’t make a significant difference. With round robin in contrast, the sender would risk sending a job to a worker that was already busy, unless it took additional measures to avoid that.
I suspect this is just an LLM hallucinating generic thread-safety boilerplate. In an async serverless runtime like Workers this pattern creates blocking risks and doesn't actually solve the distributed consistency problem.