Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!mitech!gjc
From: gjc@mitech.com
Newsgroups: comp.windows.x
Subject: Re: X & signals
Message-ID: <994@mitech.com>
Date: 26 Feb 90 09:20:38 GMT
References: <1154@sdrc.UUCP> <132200@sun.Eng.Sun.COM>
Organization: Mitech Corporation, Concord MA
Lines: 52

In article <132200@sun.Eng.Sun.COM>, argv%turnpike@Sun.COM (Dan Heller) writes:
> In article <1154@sdrc.UUCP> evgabb@sdrc.UUCP (Rob Gabbard) writes:
>> Has anyone had any problems with using alarm signals with X ? My problem is
> 
> Stop right there.  don't event *think* about using signals with X
> in its current state.  If you do, then think *really hard* because

> VMS does not support signals...
> 
> -----------------------------------------------------------
> 		    O'Reilly && Associates
> 		argv@sun.com / argv@ora.com

What rubbish, and from somebody at a place that publishes books about X.
(Or maybe your complete message was just a joke?)

The VMS implementation of XLIB could very well be the ONLY implementation
that supports ASYNC operation. The XLIB routines are reentrant and can
be called at AST level, and there is even a routine
 XSelectAsyncInput(display,window,mask,event_ast_handler,ast_arg)
which will interrupt your process when pending X-events come into
the queue.

VMS not handling signals? On the contrary, XLIB seems to have been
designed with the least-common-denominator of least-able operating systems
in mind when it comes to processing input (including clock driven).
Indeed, the nature of it is such that X (applications/server) can run in 
operating systems such as the Macintosh, where the operating system has to 
be called explicitely from the application, e.g. "SystemTask()" in order to
process user input properly.

If DIGITAL had really managed to get the X Constortium to write X in such
a way that it depended on the superior I/O/timing capabilities of VMS,
then X would have great difficulting running on other platforms.

That would not be in the best interest of DIGITAL, and X would not now
be as important as it is.

-gjc

p.s. Here is what I have to do on the Mac in order to look for the key
that a user conventionally types to interrupt a running program. It would
be nice to have more event-queue (in a general sense) procedures such as
in X. This kind of stuff even makes Unix look good.

int want_interrupt()
{SystemTask();
 for(q=EventQueue.qHead;q;q=q->qLink)
  if(q->evtQWhat == keydown && (char) q->evtQmessage == '.' &&
     (q->evtQModifiers && cmdKey))
   return(1);
 return(0);}