>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