I never studied their implementation, but IIRC this
kind of
switch_to() logic is implicit in the fast path case of a send() to a
port on which a thread is already waiting to receive(). (I don't
recall their exact terminology.)
right, but its also implicit in the fast path case of a write() to a
FIFO on which a thread is waiting to read(), so that doesn't really
buy us anything. the problem with all these mechanisms IIUC is that
they all go via the filesystem in one way or another. and because the
filesystem has to interlock in a robust way to deal with many
different kinds of situations, it will always be a slower pathway than
a direct switch. perhaps the send/receive pair via a socket doesn't
require traversing the filesystem at all. it would be interesting to
know if that's true.
in addition, i don't think that under linux any of the "fast paths"
bypass the scheduler. all that happens is that the send/write marks
the waiter runnable, and then when the scheduler runs, it will
probably execute the waiter. maybe. sometimes. etc. its a much more
complex and RT-unsafe pathway that one PID/TID saying "switch to this
PID/TID now".
now that i remember, its possible that futexes might permit something
like this, but i think it still goes through the scheduler.
The main advantage of an existing mechanism over new
ideas is that
there are years of experience with security, performance, methods of
application and other subtleties.
switch_to() has existed in some form on every Mac until OS X came
along ("cooperative scheduling"). it wasn't very good because apps
could lock up the system by denying other things the change to run.
the point here is that caller can *already* lock up the machine, so
we're not changing this "feature". we're just extending it so that it
can involve other PID/TID's in this existing DoS opportunity :)
--p