Re: running real time application behind glade

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Touch Screen Library]     [GIMP Users]     [Gnome]     [KDE]     [Yosemite News]     [Steve's Art]

  Powered by Linux