Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!apple!bloom-beacon!EXPO.LCS.MIT.EDU!kit
From: kit@EXPO.LCS.MIT.EDU (Chris D. Peterson)
Newsgroups: comp.windows.x
Subject: Re: Reading sockets from the Toolkit
Message-ID: <8905152110.AA20907@expo.lcs.mit.edu>
Date: 15 May 89 21:10:28 GMT
References: <103532@sun.Eng.Sun.COM>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 33


[ More followups on the discussion about XtAddInput]

> I hate to request this, but could you please discuss this in more detail? I
> think the question addresses more issues than it was intended-- specifically,
> I don't believe that Xt handles how the application is supposed to handle
> signals.

> The user is reading from a socket -- which is a file descriptor.  There could
> be a SIGIO event delivered to the application's event handler for that signal
> interrupting something critical within Xt.  If this routine does more Xt 
> calls, then all sorts of havoc can result.

You need to remember that not everyone has UN*X, the toolkit attempts to allow
common I/O functions for all operationg systems.  Now we can take
advantage of the fact the UN*X treates sockets the same as any other
file descriptor and use XtAddInputHandler to add a callback routine
that is called everytime there is I/O pending on the socket.  Thus
there is no need to deal with SIGIO at all, as you are not really using
signal handlers, but through some magic the Intrinsics are calling your
input handler routine when messages are pending on the socket.  Of
course this will only happen while your application is spinning in the
XtMainLoop() part of your code, so it is not quite the same as
registering a signal, but it will be more portable, and fits within the
toolkit model a bit better.


                                                Chris D. Peterson
                                                MIT X Consortium

Net:     kit@expo.lcs.mit.edu
Phone:   (617) 253 - 9608
Address: MIT - Room NE43-213