On 06/20/2018 04:59 PM, James Bottomley wrote: > I'm slightly surprised by this statement. I thought IoT Node.js > runtimes (of which there are far too many, so I haven't looked at all > of them) use libuv or one of the forks: > > http://libuv.org/ > > As the basis for their I/O handling? While libuv can do polling for > event driven interfaces it also support the worker thread model just as > easily: > > http://docs.libuv.org/en/v1.x/threadpool.html Yes, it does polling: http://docs.libuv.org/en/v1.x/design.html#the-i-o-loop > >> Similarly embedded applications, which are basically just a single >> threaded event loop, quite often don't use threads because of >> resources constrains. > It's hard for me, as a kernel developer, to imagine any embedded > scenario using the Linux kernel that would not allow threads unless the > writers simply didn't bother with synchronization: The kernel schedules > at the threads level and can't be configured not to use them plus > threads are inherently more lightweight than processes so they're a > natural fit for resource constrained scenarios. > > That's still not to say we shouldn't do this, but I've got to say I > think the only consumers would be old fashioned C code: the code we > used to write before we had thread libraries that did use signals and > poll() for a single threaded event driven monolith (think green > threads), because all the new webby languages use threading either > explicitly or at the core of their operation. Regardless of how it actually might be used, I'm happy that we agree on that this *is* the right thing to do. Thanks, Tadeusz
