Re: A better interface, perhaps: a timed signal flag

[Steven Rostedt <rostedt@goodmis.org>]

On Fri, 2006-07-28 at 21:01 +0100, Alan Cox wrote:
> Ar Gwe, 2006-07-28 am 12:44 -0400, ysgrifennodd Steven Rostedt:
> > But for real-time applications, the signal handling has a huge latency.
> 
> For real-time you want a thread. Our thread switching is extremely fast
> and threads unlike signals can have RT priorities of their own
> 

You mean to have a thread that does a nanosleep till the expected
timeout, then write some variable that the other high prio thread can
see that the timeout has expired?

Hmm, so that register_timeout can be implemented with at thread that
does a nanosleep then updates the flag.

The only problem is that the thread needs to go up to a higher priority
(perhaps the highest), which means that this can only be implemented
with special capabilities. Then again, pretty much all RT tasks are
special, and usually run with privileged capabilities.


There's also something else that would be a nice addition to the kernel
API.  A sleep and wakeup that is implemented without signals. Similar to
what the kernel does with wake_up.  That way you can sleep till another
process/thread is done with what it was doing and wake up the other task
when done, without the use of signals.  Or is there something that
already does this?

-- Steve