>- either get it to estimate when the buffer may be ready again and
>sleep, or get it to request a signal of some sort from the critical
>process. This might be a real signal, a semaphore, a byte over a pipe
>- but all of these involve some overhead (although not a risk of
>blocking) for the critical process.
just a footnote: its not true that these methods don't run the risk of
blocking. until the BKL (Big Kernel Lock) is totally removed from the
Linux kernel, *any* system call (read/write/semop, whatever) might
block, at least on an SMP system.
and the estimated sleep method cannot work, because the kernel offers
no way to sleep for less than 1 timer tick, which is 10ms by default
(i.e. 99% of all x86 linux systems). yes, i know that RT_FIFO threads
will busy-wait, for smaller time periods on SMP systems but that
doesn't count as "sleeping" in my book.
--p
