On Wed, 2018-06-20 at 18:24 -0700, Tadeusz Struk wrote:

On 06/20/2018 04:59 PM, James Bottomley wrote:

quoted

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.

quoted

quoted

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