pusateri@romeo.cs.duke.edu (Thomas J. Pusateri) (05/04/89)
Could some knowledgeable Toolkit programmer suggest the best way to add a new event to the toolkit main loop XtMainLoop() that will execute my callback function when data comes in over a socket. I am using Athena widgets if that makes a difference. Thanks, Tom Pusateri National Biomedical Simulation Resource Duke University Medical Center pusateri@romeo.cs.duke.edu
kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) (05/06/89)
> Could some knowledgeable Toolkit programmer suggest the best way to add > a new event to the toolkit main loop XtMainLoop() that will execute my > callback function when data comes in over a socket. I am using Athena > widgets if that makes a difference. Take a look at section 7.1.1 (Adding and Removing Input Sources) in the X11R3 instrinsics manual I think this is exactly what you are looking for. Chris D. Peterson MIT X Consortium Net: kit@expo.lcs.mit.edu Phone: (617) 253 - 9608 Address: MIT - Room NE43-213
argv%eureka@Sun.COM (Dan Heller) (05/08/89)
In article <8905052147.AA00039@expo.lcs.mit.edu> kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) writes: > > Could some knowledgeable Toolkit programmer suggest the best way to add > > a new event to the toolkit main loop XtMainLoop() that will execute my > > callback function when data comes in over a socket. I am using Athena > > widgets if that makes a difference. > > Take a look at section 7.1.1 (Adding and Removing Input Sources) in > the X11R3 instrinsics manual I think this is exactly what you are looking > for. > Chris D. Peterson 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. dan <argv@sun.com>
kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) (05/16/89)
[ 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