herrage@ntpal.UUCP (Robert Herrage) (07/12/90)
Many thanks to those of you who responded so quickly, and precisely to my question about using XtAddInput so that XtMainLoop could watch a socket as well as X events. Is there a way to do the same thing for semaphores? Any help would be greatly appreciated! Robert
lih@cunixf.cc.columbia.edu (Andrew "Fuz" Lih) (07/12/90)
In article <490@ntpal.UUCP> herrage@ntpal.UUCP (Robert Herrage) writes: >Many thanks to those of you who responded so quickly, and precisely >to my question about using XtAddInput so that XtMainLoop could watch >a socket as well as X events. > >Is there a way to do the same thing for semaphores? Well, at AT&T, we use Xt+ which is based on the X11R3 Intrinsics. There seems to be a bug with Open Look 2.0 End User release package since XtAddInput() does not work as advertised in the manual, so we use an alternative method for handling non-blocking I/O that can be generalized for semaphores or any other flag that signals a resource that is ready to be processed. We use the XtAddTimeOut() call which takes two arguments: one is the name of your call back function, and the second integer tells how many seconds XtMainLoop() should wait before calling that function. While this call is usually used in applications that need strict "wall-clock" timing, you can use this to set up a polling routine that periodically polls a flag, or in your case, a semaphore. Note that after XtAddTimeOut() is called, the callback and timeout are "unregistered", so that if the check on your flag/semaphore is unsuccessful, you will have to "re-register" your callback. That is: ... XtAddTimeOut(1000, check_flag, ...); ... void check_flag() { if (flag == 0) { printf("Great news, safe to enter!\n"); do_service(); } else { printf("Bad news, it ain't ready yet\n"); XtAddInput(1000, check_flag, ...); } } No, this is not the most elegant way of doing things, but it does prevent XtMainLoop() from stalling when waiting on a flag or semaphore. The integer argument for XtAddInput() is the number of milliseconds to wait before calling the function. You may want to make this larger or smaller depending on your client's needs. This is is just one of several solutions we considered, I would be happy to hear other suggestions from the net. Andrew Lih AT&T Bell Labs lih@probe.att.com (Guest at Columbia University) ___________________________________________________________ """""""""" / \ | @ @ | | Andrew "Fuz" Lih Columbia University Center | < > > ___/ Academic Computing for Computing Activities |