> > > >Will it be possible to write hard-realtime applications under hurd[?] I > > > >have heard that it is possible under linux if you link your application > > > >into kernel space like a driver module. > > > This would be very cool. It should support multimedia apps and > > > synchronizing different multimedia streams. > > [...] > > By the way, I think we are talking about different kind of realtime. > > > > With "Hard realtime" i mean that the application can preempt the kerenl > > itself. When the application can preempt the OS ( like when you sets > > nicelevel to -20 ) I talk about it as "Soft realtime". > > I think what you're referring to as "soft realtime" is just what everybody > else calls "scheduling". :-)
Okay, realtime is not equiallent to nicelevel -20. An app with nicelevel -20 will preempt parts of the OS, but does not need to be "realtime". :) However, I wasn't at all talking about "soft realtime" or "scheduling" because I presumed that Hurd allready has got it. "Hard realtime" is different. With "Hard realtime" the OS must be able to guarantee that if I receieve a specific hardware signal, then my signal handler will be called immediately, *not* after it has been handled by a sheduler, but immediately, and with no lag. The signal handler must *not* have been swapped out, or something. The OS should be able to guarantee a maximum count of CPU clock ticks that occurs before my signal handler is called. ( And I must guarantee that my handler don't break the system :) > > I don't think you would like to run a multimedia app in hard realtime > > because it would probably violate the stability of the entire system. > > I don't agree. What some kernels (QLinux and Nemesis, for instance) ( Most "hard realtime" implementations I know about run in kernel-mode. However, most realtime applications are not "hard realtime". ) > implement, and what the second poster above was referring to, is quality of > service; an application can say to the kernel "I need to produce one block > of audio data every 2ms", and the kernel will guarantee that the application > can do that. As long as you implement limits---you don't want a rogue user > coming along and running a task which requests a 2Gb data transfer from the > hard disk every 1ms---then it shouldn't have any effect on data stability. > > This sort of thing in a mainstream OS would make Hurd a great platform for > video and audio editing---and games too. :) I agree! But, can the Hurd really guarantee such things? All system calls go through a socket, right? Can these sockets guarantee that data will be transfered within a defined timelimit? Is anything designed with realtime, or at least "quality of service"? // Liss
