rcruz@paul.rutgers.edu (Rafael Cruz) (07/01/90)
Hello,
I had *limited* experience with X while developing a simulation package for the
time-domain response of a control system; what I have seen so far about X is
very exciting and the notion of a network transparent window system will be
highly desirable in the project I am about to begin. Given all that:
- What mechanism does the X server use to handle events?
- Can this mechanism be accessed to porvide the functionality to do
things such as priority-based preemptive scheduling tasks.
- If the X server can't be used directly in a real-time application,
can I still work around its limitations and sort of take over the
handling of time-critical events, by programming say at Xlib level,
in an efficient manner?
Thanks in advance for your comments and suggestions.
-----
Rafael Cruz
rcruz@paul.rutgers.edubarmar@think.com (Barry Margolin) (07/07/90)
In article <Jun.30.15.22.54.1990.3479@paul.rutgers.edu> rcruz@paul.rutgers.edu (Rafael Cruz) writes: > - What mechanism does the X server use to handle events? The X server doesn't *handle* (i.e. respond to) events, it *generates* them (in response to user actions on the physical keyboard and mouse) and sends them to the appropriate client applications. The mechanism in the server to detect user actions that should provoke events is generally system- and hardware-dependent. Clients use whatever mechanisms are provided by their operating system to detect input from a network connection (if the client and server are separated by a network) in order to handle events. For instance, Unix clients probably use select() (either explicitly or internally within the Xlib library) to wait for an event, but they could also turn on signalling on the socket (if they're careful to deal with the fact that Xlib isn't re-entrant, so the signal must be masked during calls to X routines). > - Can this mechanism be accessed to porvide the functionality to do > things such as priority-based preemptive scheduling tasks. I'm not sure whether you're asking 1) whether X can be used to implement this, or 2) whether X will make use of such mechanisms if they exist. 1) If the OS doesn't provide these things, X certainly can't add it. X generally contains no kernel modifications, and very little of it is even privileged (on Unix, xterm is usually setuid so that it can add entries to the utmp database, and the X server may need to be setuid so it can access the frame buffer device). 2) An Xlib implementation for a real-time OS *should* make use of the OS's event-handling and scheduling mechanisms to handle X events. Whether any particular Xlib implementation does so is a function of how much effort the porter put into optimizing Xlib for that environment and how similar that environment is to BSD Unix, since that is the environment of the implementors of the sample Xlib. > - If the X server can't be used directly in a real-time application, > can I still work around its limitations and sort of take over the > handling of time-critical events, by programming say at Xlib level, > in an efficient manner? I'm not sure whether I'm confused about what you're asking, or whether you're misusing the term "X server". The "X server" is the program running in the processor (usually) physically connected to the keyboard, mouse, and display. Many are ports of the sample X server, which is single-threaded. I suspect that there would be little gain in making the server multithreaded, as the commands that can be sent to the server are very simple and atomic; in a multithreaded server the scheduling overhead would probably be more than the delay inherent in the current serializing of all commands, and there would also be the locking overhead due to the fact that most commands operate on a single shared resource, the frame buffer. (Actually, most X terminals do seem to be multithreaded, but the X server probably runs in a single thread. The other threads are for setup menus, a telnet client, etc., which are not involved with the X protocol.) -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar