3 ms·

Concurrency is about how you organize a solution really more than anything. Whether those concurrent tasks execute in parallel or not is a different considerati

Concurrency is about how you organize a solution really more than anything. Whether those concurrent tasks execute in parallel or not is a different consideration. Many authors and experts conflate these terms. You can write concurrent code with pthreads. It may happen to execute in parallel but it doesn't have to. In fact, I believe the early SunOS/Solaris pthreads had a 'green' scheduler where it could all be done in userspace (this is from my own memory nearly 20 years ago). This made them basically "stack switchers" which is what some lightweight coroutine libraries end up doing. Having written heavily callback-driven code. Threading contexts manually, thinking about object lifetimes, I can say that coroutines have a much cleaner flow to them and can make it easier to write and later read and debug programs than crazy callbacks and contexts. Object lifetimes are one thing coroutines help with in a big way. I think it's why Rust is so attractive to so many. Look at plan 9's libthread for example: https://github.com/9fans/plan9port/tree/master/src/libthread https://github.com/9fans/plan9port/tree/master/src/libthread It allows one to take advantage of nonblocking sockets as a single "kernel execution entity" mechanism across many userspace threads. This approach works pretty well. The Mongrel2 webserver clearly borrows this approach in their task library: https://github.com/9fans/plan9port/blob/master/src/libthread/386-ucontext.h https://github.com/9fans/plan9port/blob/master/src/libthread... https://github.com/mongrel2/mongrel2/blob/master/src/task/386-ucontext.h https://github.com/mongrel2/mongrel2/blob/master/src/task/38...

mhink 9y ago
> Having written heavily callback-driven code. Threading contexts manually, thinking about object lifetimes, I can say that coroutines have a much cleaner flow to them and can make it easier to write and later read and debug programs than crazy callbacks and contexts. This is the biggest reason I vastly prefer using coroutines in my Javascript projects (by way of `redux-saga` if there's heavy lifting, or just async/await otherwise). > Concurrency is about how you organize a solution really more than anything. You hit the nail on the head here. IMHO, business logic should be expressed procedurally, whereas driver code in an event-loop driven environment (like V8) is more suited to a functional style. Coroutines let you do both, quite cleanly. Thanks for the links, btw, I've been wanting to dig through other code like this in more established languages. :)

mhink 9y ago

> Having written heavily callback-driven code. Threading contexts manually, thinking about object lifetimes, I can say that coroutines have a much cleaner flow to them and can make it easier to write and later read and debug programs than crazy callbacks and contexts. This is the biggest reason I vastly prefer using coroutines in my Javascript projects (by way of `redux-saga` if there's heavy lifting, or just async/await otherwise). > Concurrency is about how you organize a solution really more than anything. You hit the nail on the head here. IMHO, business logic should be expressed procedurally, whereas driver code in an event-loop driven environment (like V8) is more suited to a functional style. Coroutines let you do both, quite cleanly. Thanks for the links, btw, I've been wanting to dig through other code like this in more established languages. :)