4 ms·
> I've yet to find a single use-case for it in my projects. This is the “concurrency vs parallelism” that (e.g.) Rob Pike goes on about[0], rightfully. I think
by bch 7y ago
> I've yet to find a single use-case for it in my projects.
This is the “concurrency vs parallelism” that (e.g.) Rob Pike goes on about[0], rightfully. I think to the uninitiated it can be tough to grasp (not commenting on whether YOU understand or not...). I use it daily, depending on circumstances, w a single-threaded network client that concurrently manages connections to perhaps hundreds of other machines. Most of the wall-time is spent waiting for something to occur on one of the remotes; “waiting in parallel” isn’t going to speed anything up, and nothing happens outside of the relatively infrequent events from the outside network to my client. I can’t forecast what is going to arrive on which socket, so I wait, and process asynchronously. GUIs will operate this way too. The pattern is suitable where you’re in a situation where: “something might happen sometime and I’ll need to do a (quick) bit of work in response”
[0] https://youtu.be/cN_DpYBzKso https://youtu.be/cN_DpYBzKso
- gdxhyrd 7y agoThe same can be achieved easily with non-blocking IO with an event loop. In addition, several threads will go faster than one as soon as any two remotes overlap.