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:	Sun, 21 Jan 2001 22:02:26 +0100
Message-ID:	<NEBBIOJNGMKPNOBKHCGHAEOLCAAA.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:	<4634-Sun21Jan2001212234+0200-eliz@is.elta.co.il>
Importance:	Normal
X-MimeOLE:	Produced By Microsoft MimeOLE V5.50.4133.2400
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id QAA12294
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

> This looks okay, but where is the signal handler, the one whose name
> is passed to signalAfter in the func argument?
gdb shows smalltalk hooking SIGFPE, SIGINT and SIGSEGV at startup.
This is the hook:

RETSIGTYPE
interruptHandler(sig)
     int	sig;
{
  setSignalHandler(sig, SIG_DFL);

  switch (sig) {
  case SIGFPE:
    if (inInterpreter) {
      setSignalHandler(sig, interruptHandler);
    } else {
      kill(getpid(), sig);
    }
    return;

  case SIGINT:
    if (nonInteractive) {
      printf("Signal %d, exiting...\n", sig);
      if (ip) {
        showBacktrace();
      }
      exit(1);
    } else {
      setSignalHandler(sig, interruptHandler);
      stopExecuting("userInterrupt");
      return;
    }

#ifdef SIGBUS
  case SIGBUS:
    errorf("Bus error");
    break;
#endif

  case SIGSEGV:
    errorf("Segmentation violation");
    break;

  default:
    errorf("Unknown signal caught: %d", sig);
  }

  debug();
  if (inInterpreter) {
    /* Avoid recursive signals */
    inInterpreter = false;
    showBacktrace();
  } else {
    errorf("Error occurred while not in byte code interpreter!!");
  }

  kill(getpid(), sig);
}

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;
}

I really don't see anything wrong with this though - nor do I see
something that would interfere with __dpmi_yield. But this _might_
have a bearing on it:

void
asyncSignal(semaphoreOOP)
     OOP semaphoreOOP;
{
  IntState oldSigMask;

  oldSigMask = disableInterrupts(); /* block out everything! */
  queuedAsyncSignals[asyncQueueIndex++] = semaphoreOOP;
  setExceptFlag(true);
  enableInterrupts(oldSigMask);
}

Perhaps this disable/enable stuff causes trouble?

> I actually think that running the SIGALRM code under a debugger is not
> a good idea, as I wrote earlier, because it causes some strange
> interference with the debugger.  But if the main Smalltalk program
> rarely or never uses timers, you can run it inside GDB.
Only a smalltalk program using certain statements would use a timer,
AFAICS.

> In any case, if you do run the timer code under GDB, don't forget to
> say "handle SIGALRM noprint nostop".
Did. Worked. At least, the program got the SIGALRM and exited with
a traceback; gdb was unaffected - which is what was supposed to
happen, I guess.

- Raw text -