News for hackers. Stuff that matters.
Re:Async-std: an async port of the Rust standard library by rmgraham on Friday August 16, 2019 @04:50PM (#20719562)
Are those really the only options? I'm trying to wrap my head around how using a fixed size thread pool for I/O automatically implies deadlocks but I just can't. Unless the threads block on completion until their results are consumed instead of just notifying and then taking the next task..

I can definitely imagine blocking happening while waiting for a worker to be available, though. Did you mean simply blocking instead of deadlock?

Re:Async-std: an async port of the Rust standard library by spullara on Friday August 16, 2019 @05:10PM (#20719745)
N threads, with N readers waiting for a message that will only come if the N+1 reader (still in the queue) gets a message first.
Re:Async-std: an async port of the Rust standard library by rmgraham on Saturday August 17, 2019 @04:32PM (#20726158)
Thank you for humoring me. I had to sleep on it, but I can see it now. Seems like it would require a really bad design or more likely bad actors (remotes leaving dead sockets open), but it would definitely be possible.

The same scenarios would lead to resource exhaustion if the thread pool wasn't bounded.

Re:Async-std: an async port of the Rust standard library by nine_k on Saturday August 17, 2019 @12:13AM (#20721988)
But sure one must use an output queue, not synchronously wait for the consumer to consume a result?
Re:Async-std: an async port of the Rust standard library by spullara on Saturday August 17, 2019 @02:11AM (#20722455)
The N + 1 readers are all reading different sockets, blocked.