On Wed, 2018-06-20 at 18:24 -0700, Tadeusz Struk wrote: > 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 But that's for networking. You'll be talking to the TPM RM over the file descriptor so that follows the thread pool model in http://docs.libuv.org/en/v1.x/design.html#file-i-o This precisely describes the current file descriptor abstraction we'd use for the TPM. > > > 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. I didn't say that. I think using a single worker thread queue is the correct abstraction for the TPM. If there's a legacy use case for poll(), I don't see why not since the code seems to be fairly small and self contained, but I don't really see it as correct or necessary to do it that way. James
