Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!samsung!think!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: X & signals
Message-ID: <9002281550.AA00282@expire.lcs.mit.edu>
Date: 28 Feb 90 15:50:54 GMT
References: <132219@sun.Eng.Sun.COM>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 25


    Whatever the case, if Xt is going to
    handle the lower levels for the real toolkit (widget set), then why
    not provide something like XtAddSignalHandler(signal, handler).

Xt and Xlib interfaces are generally designed to be OS independent.  I don't
know if a "generic" design is possible here (that may be part of the problem).

    I would
    be happen if the X doc or the consortium gave some sort of recommendation
    about what to do with signals rather than avoiding the whole issue.

I don't think I've ever seen a good exposition of the "problem with signals",
and what the application requirements really are.  I don't know if there's
consensus on the requirements.  Not knowing VMS ASTs, I don't know how the
requirements match those for VMS programmers.  Without a reasonable set of
requirements, it's hard to propose or evaluate a mechanism.

By your signature line, you work for a member of the X Consortium.  The
X Consortium doesn't do things by magic, it takes people willing to do work.
I haven't seen many people in the Consortium express concern about this issue,
but that doesn't mean they wouldn't be willing to adopt something if someone
was willing to do the work.  Perhaps you'd like to write up what the issues
are, propose a design, write it up, supply a sample implementation, and help
the X Consortium solve the "problem with signals".