Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uwm.edu!linac!att!cbnewsh!tjt
From: tjt@cbnewsh.att.com (timothy.j.thompson)
Newsgroups: comp.windows.x
Subject: Re: What's the disadvantage of X Window ?
Message-ID: <1991May16.151119.20728@cbnewsh.att.com>
Date: 16 May 91 15:11:19 GMT
References: <9105160040.AA05160@lightning.McRCIM.McGill.EDU>
Organization: AT&T Bell Laboratories
Lines: 23

From article <9105160040.AA05160@lightning.McRCIM.McGill.EDU>, by mouse@lightning.mcrcim.mcgill.EDU (der Mouse):
> And in any case, this does not imply that it is unusable in real-time
> applications, only that the real-time part must not depend on X.  For
> that matter, most UNIX systems (UNIX being, in some sense, the "native"
> operating system for X) are badly suited to real-time work; I know, I
> was involved in building the operating system interface for a robot
> control system with a 28-millisecond cycle time.

This advice is certainly the safest and best in general.  The situation
is changing, though, for some realtime applications.  For several years,
I've been using UNIX and X Windows for a "realtime" application with a
10-millisecond "requirement", and have been quite happy.  The application
is MIDI, and graphics (e.g. flashing notes as they play) can be done in
realtime without audibly affecting the timing.  (This is on a 20 Mhz 386.)
There are of course limits - there will always be limits.  With System V
Release 4, realtime performance can even be "guaranteed", by using the
realtime scheduling class.  To *recommend* this setup to people who would
not normally consider UNIX for other reasons (e.g. because they want
email, familiarity, etc.) is to invite complaints, though.  I can only say
that it works for me (and a handful of other people who use it as their
only MIDI sequencer), and demonstrate it (e.g. at the upcoming USENIX).

                                        ...Tim...tjt@blink.att.com...