On Tue, 02 Nov 2004 20:07:51 +0100, =?ISO-8859-1?Q?Jos=E9_Antonio_S=E1nchez?= said: > Maybe he is testing the real time kernel to use it on a real time > project. I had to make a lot of dummy tests for my application before > starting with the real work only to get started with the RTAI API. So > this test (if that's a test) it's right. Well, yes.. but I haven't actually *seen* anything that actually points to that (not even a "eventually we will be doing manufacturing process control that needs real-time support"). And for every person I see that is *really* doing real-time programming, I see at least several dozen that *think* they need it, when the actual requirement is the *much* simpler "keeping multiple processes synchronized".... > That's not usual. The real time kernel runs below the Linux kernel. In > fact, with RTLinux and RTAI the Linux kernel is some kind of idle > thread, so Linux is executing when it needs and only interrumped by > real time tasks when it's time. No matter if a system call is executed > because all the Linux environment is apart from the real time tasks. That's specific to one particular implementation of real-time. And if you trace it through, I'm *still* right - because in that case, the RTLinux code has decided the *entire* Linux kernel won't get scheduled, because it has to fulfill a real-time commitment. The point still remains - in *any* hard real-time system, the software managing the scheduling is totally permitted to *totally* starve any and all non-real-time code in order to fulfill a real-time commitment. This can easily lead to "the GUI is totally locked up" issues.... > Here you are right. There can't be a GUI process in real time. You > need a separate thread (or kernel module) to execute real time tasks. > In fact, a real time task can't make any Linux system call. And even more importantly for program design - communication to/from the real-time thread from the GUI has to be *very* carefully designed, because you're not allowed to do anything that could *possibly* block on the real-time end. Careful design of locking and semaphores is required....
Attachment:
pgpYOsXNu2QCL.pgp
Description: PGP signature
_______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
