From:	"Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To:	<djgpp-workers AT delorie DOT com>
Subject:	RE: Interaction between __dpmi_yield and signals?
Date:	Mon, 22 Jan 2001 19:04:14 +0100
Message-ID:	<NEBBIOJNGMKPNOBKHCGHOEPHCAAA.tim.van.holder@pandora.be>
MIME-Version:	1.0
X-Priority:	3 (Normal)
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To:	<Pine.SUN.3.91.1010122101152.25334E-100000@is>
X-MimeOLE:	Produced By Microsoft MimeOLE V5.50.4133.2400
Importance:	Normal
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id NAA03195
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> > When the delays test is run (the one with the failing SIGALRM),
> > it hooks SIGALRM to this:
> > 
> > RETSIGTYPE
> > timeoutHandler(sig)
> >      int	sig;
> > {
> >   setSignalHandler(sig, SIG_DFL);
> >   asyncSignal(timeoutSem);
> >   timeoutSem = nilOOP;
> > }
> Is it possible that SIGALRM happens more than once?  If so, the second
> time will abort the program, because the above handler resets the
> SIGALRM handler to SIG_DFL.
Yes, but the function that sets the alarm in the first place, first sets
the signal handler to the function it's passed (i.e. timeoutHandler).
So I don't see how they could overlap.

> What do disableInterrupts() and enableInterrupts() do?  What
> ``interrupts'' do they disable/enable?

IntState
disableInterrupts()
{
  sigset_t	  newSet;
  static sigset_t oldSet;

  if (disabled) {
    /* let only the outermost calls actually block and unblock signals */
    return ((IntState) NULL);
  }
  disabled = true;
  sigfillset(&newSet);
  sigprocmask(SIG_BLOCK, &newSet, &oldSet);
  return ((IntState) &oldSet);
}

void
enableInterrupts(newSet)
     IntState newSet;
{
  if (newSet) {
    disabled = false;
    sigprocmask(SIG_SETMASK, (sigset_t *) newSet, NULL);
  }
}

are the ones used for DJGPP (since we have SIG_BLOCK).

> In general, I doubt if this is the problem, since this code runs
> _after_ SIGALRM already happened, and it runs from the SIGALRM
> handler.  By contrast, the traceback you showed indicates that the
> default (i.e. SIG_DFL) handler was called.
Yep. Sure looks that way...

What I expect happens is that the __dpmi_yield() takes so 'long' that
a second alarm gets set (if two alarms are set, do they BOTH fire?)
before the first one is done; then the signal handler will be set to
SIG_DFLT by the time the second alarm fires (even though it had set
the hook to timeoutHandler).

- Raw text -