Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!imagen!atari!portal!portal!cup.portal.com!thinman
From: thinman@cup.portal.com (Lance C Norskog)
Newsgroups: comp.windows.x
Subject: Re: Problem with Signals
Message-ID: <27969@cup.portal.com>
Date: 17 Mar 90 22:05:24 GMT
References: <9003111041.AA24486@Larry.McRCIM.McGill.EDU>
Organization: The Portal System (TM)
Lines: 40

You're all going about this the wrong way.  The original poster with
the 7-hour operation can easily do what I did:

I wanted to get into X programming, and I wanted to look at some PostScript
stuff, so I brought up the Crispin Goswell postscripter X driver.
It doesn't handle X input well, but Berkeley sockets and AT&T Streams
both have a facility to deliver a signal on receipt of data on a network
connection.  Under SYSV it's SIGPOLL, under BSD I think it's SIGASYNC.

I don't use XtMainLoop at all.  The init routine does this:
	
	for (fd=3; fd<100; fd++)
		if fd is a network socket
			make fd send the input-available signal

	This is, admittedly, grody, but Xt won't find the fd's for me.

The signal handler for this sig sets a flag and exits.

Periodically you check that flag and run this routine:
	
	XtInputMask mask;

	while(mask = XtAppPending(applicationcontext))
		XtAppProcessEvent(applicationcontext, mask)

Under SYSV, this pair stops sigs and then handles them:
	sighold(SIGPOLL);	/* single-thread this routine */
	sigrelse(SIGPOLL);	/* take more signals now */

Using polling when interrupts are available is extremely goony.
If you follow the other suggestions in this thread, your 7-hour calculation
will become 8 or 9 or 10 hours, because of all the polling involved.

The only problem with this scheme under SYSV is that signals always make
system calls return with EINTR, so I had to guard all file I/O with 
sighold/sigrelse pairs and play games with the command line I/O handler.
Also, there are sighold/sigrelse pairs around all X driver routines.

Lance