Subject: RE: upcalls?
To: None <firstname.lastname@example.org>
From: Martin Husemann <email@example.com>
Date: 12/12/1999 18:16:18
Jon Lindgren wrote:
> I'd hope that at least pthreads will be exposed. While it may not be the
> best API, and while it probably won't expose all functionality, it is
> rather standard.
Well, that's only part of an answer. It's a library level interface, not an
interface between kernel and userland. Of course we should have a pthreads
implementation fine-tuned to the ABI we provide, but I think that ABI needs
some discussion (and this discussion IMHO should happen before
implementation details are fixed) unless (a) there already is some
relevant, formal standard we could follow or (b) there is good prior art we
I don't know about (a) and suppose there is multiple (different) prior art,
so (b) would need/cause a discussion by itself.
The scheduler activation concept is cool, and may be worth to follow, but it
still leaves a lot of variables to decide upon.
If we decide to do scheduler activations, I'd suggest to have an interface
to "raw kernel based user threads" as well (Anderson et. al. left it in for
compatiblity reasons, but I think it has its value of its own and probably
won't cause much additional implementation costs).
And I realy like an additional interface for asynchronous IO primitives.
Using this in applications needs a different style of coding [often quite
complex, if done properly with extensive error checking], but for some tasks
is quite natural and can be very effective (no context switch or
callback/event if data is already available).
Then I prefer threads to have some global meaningful priority, not just
processes. Of course this can be easily fixed in scheduler activation
And last point: applications using spin locks in userland deserve starvation
or deadlocks (Anderson et.al. mention avoidance of this as one of their pros
vs. other userland-thread-implementations). We should provide an escalating
lock primitve, that does a few spins and after reaching a threshold
automatically switches to blocking on a waitable object (like the new
CRITICAL_SECTION version introduced by NT 4.0 SP3 with
So again the question: what standards or prior art is available online or
should be considered, any other references, personal preferences...?
Or have those-with-the-power-to-decide already done so - then please tell us