SODA Noriyuki wrote:
> For "hard realtime" purpose, I think current interrupt-based model is
> best at least while predictable future.
> Unix-like kernel is too complicated and it's really too hard to
> identify longest code path until a realtime process gets scheduled.
> Interrupt based model is far easier to see the worst case, and
> I believe this is the only doable way for some time, if you really
> want hard realtime application.
> Linux kernel is better than NetBSD about fine-grained locking,
> but it's still far far away from hard readtime process scheduling.
> 
> If you only need soft realtime, it's different, of course.

What do you think is meant with:

"We need real-time scheduling support, POSIX real-time extensions, and 
thread-safe libraries. There is an increasing number of applications 
related to video, voice, and control that need hard real-time support. 
We can start by bullet-proofing our thread support and finishing the 
re-entrancy issues with our libraries, then continue by evaluating 
real-time scheduling and making subsystems of our kernel able to use 
multiple processors."

From: [Also available at 
http://www.netbsd.org/Foundation/reports/2004.html] Report of the 2004 
Annual NetBSD Group Meeting


Does any of this sound reasonable? It sounds mostly out of reach at the 
time, don't you think. One could improve on the scheduler, or imnplement 
POSIX real-time stuff like "realtime" priorities - but it would just be 
a facade with not much to back it up, don't you think?

At least it sound like a long-long-long-term goal! ;)

With kind regards,
Oliver Korpilla