Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!uunet!bischeops!nick
From: nick@bischeops.UUCP (Nick Bender)
Newsgroups: comp.windows.x
Subject: Re: Problem with Signals
Summary: how bout this
Message-ID: <388@bischeops.UUCP>
Date: 9 Mar 90 17:41:21 GMT
References: <9002281729.AA02895@wilkins.bcm.tmc.edu> <132399@sun.Eng.Sun.COM> <203@samna.UUCP>
Lines: 82



In article <203@samna.UUCP>, jeff@samna.UUCP (jeff) writes:
> In article <23695@masscomp.ccur.com> mitch@westford.ccur.com (Mitchel Kuninsky) writes:
> :I envision a signal handler like:
> :
> :	SignalHandler
> :	{
> :	    sigFlag = TRUE;
> :	}
> :
> :and an XtMainLoop like:
> :
> :	MyMainLoop()
> :	{
> :	    XEvent event;
> :
> :	    for (;;)
> :	    {
> :(1)		XtNextEvent( &event );
> :		if (event.type != NULL_EVENT)	/* or something like this. */
> :		    XtDispatchEvent( &event );
> :		if (sigFlag)
> :		{
> :		    process signal.
> :		    Inhibit signals.
> :		    sigFlag = FALSE;
> :(2)		    Enable signals.
> :		}
> :	    }
> :	}
> 
> This may be kind of nit-picking, but ... You have a nasty race here.
> What if a signal arrives between the re-enabling of signals at (2) and
> the next call to XtNextEvent at (1).
> 
> I believe this points out the need to have the signal-handling more
> tightly integrated with the Intrinsics code.
> 
> ---
> Jeff


I've been thinking a little about this problem and had the following idea:

  Boolean sigSet[MAX_SIGNALS];
  static struct timeval pollTimeout = { 0, 0 };
  static struct timeval *timeoutPtr;
  static fd_set *inputSetPtr;

  void SetSignalFlag (sig)
  {
    sigSet[sig] = TRUE;
    timeoutPtr = &pollTimeout;
  }

  SuperLoop()
  {
    while (whatever)
    {
      timeoutPtr = NextTimeoutTime();
(1)   UnblockSignals();
      nready = select (NOFILE, inputSetPtr, 0, 0, timeoutPtr);
(2)   BlockSignals();
      ExecuteRunnableThreads();
    }
  }

So the question is, will the select always return with EINTR or after
a polling call? Of course it doesn't deliver true async execution be
cause it assumes that all you do is set the flag in the interrupt handler,
but does it eliminate the race condition (does it *always* prevent the
select call from hanging indefinitely given no scheduled timeouts)?
Do I *always* get what I want no matter what point the signal or signals
hit between (1) and (2) ?

Any thoughts ?

PS. I'm assuming the BSD style sigvector signal mechanisms (you know,
reliable delivery and all that...).

path nick%bischeops@uunet.uu.net