3 ms·
If you insist on making it as difficult as possible, I guess. Otherwise the producer decides when the show stops, by simply closing the channel.
by codr7 6y ago
If you insist on making it as difficult as possible, I guess.
Otherwise the producer decides when the show stops, by simply closing the channel.
- earthboundkid 6y agoYes, exactly. The workers can send results to the manager, but the manager does all the management. Anything else gets too hairy, too fast to reason about. I wrote a blog post about it: https://blog.carlmjohnson.net/post/share-memory-by-communicating/ https://blog.carlmjohnson.net/post/share-memory-by-communica...
- Animats 6y agoDoes that scale to a pipeline, a chain of producers and consumers? What happened with Go, I suspect, is that the syntax came first. Go uses a "<-" operator to talk to channels. There's no place for an error status with that operator. Hence the problem. UNIX-type pipelines have SIGPIPE to unwind things when something downstream aborts. Abort has to propagate back up the chain. I tend to argue that the workarounds for not having exceptions are worse than the problems of exceptions.
- fovc 6y agoThe ECMAScript TC came to the same conclusion with promises and fetch. Instead of adding an `.abort` method to promises for the consumer to use, you need to wire in an AbortController so that the producer (fetch) can close the channel. The consumer then sees an AbortError. It's a bit more work to wire up than simply calling `p.abort()`, but it saves you from having to reason through some hairy race conditions.