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 19:09:07 +0100
Message-ID: <NEBBIOJNGMKPNOBKHCGHMEOICAAA.tim.van.holder@pandora.be>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-reply-to: <7458-Sun21Jan2001181716+0200-eliz@is.elta.co.il>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id NAA05270
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
Precedence: bulk

> Then you might consider replacing itimer.c with what's currently in
> the CVS: there was a small bug in the released version.  I don't know
> if it affects this specific problem, but you never know...
Will try that.

> Please show the code which sets up the timer and the signal handler.
Seems to be this:

void
signalAfter(deltaMilli, func)
     int deltaMilli;
     RETSIGTYPE (*func)();
{
/* Please feel free to make this more accurate for your operating system
 * and send me the changes.
 */
  setSignalHandler(SIGALRM, func);

  if (deltaMilli <= 0) {
    kill(getpid(), SIGALRM);
  } else {

#ifdef WIN32
#define ALARM_DONE
    WaitForSingleObject(alarms.hCritEvent, INFINITE);
    alarms.sleepTime = deltaMilli;
    SetEvent(alarms.hCritEvent);
    SetEvent(alarms.hNewWaitEvent);
#endif

#if defined(ITIMER_REAL) && !defined(ALARM_DONE)
#define ALARM_DONE
    struct itimerval value;
    value.it_interval.tv_sec = value.it_interval.tv_usec = 0;
    value.it_value.tv_sec = deltaMilli/1000;
    value.it_value.tv_usec = (deltaMilli%1000) * 1000;
    setitimer(ITIMER_REAL, &value, (struct itimerval *)0);
#endif

#if defined(HAVE_FORK) && !defined(ALARM_DONE)
#define ALARM_DONE
    static pid_t pid = -1;
    long end, ticks;
    if (pid != -1) {
      kill(pid, SIGTERM);
    }
    setSignalHandler(SIGCHLD, SIG_IGN);
    switch(pid = fork()) {
      case -1:
	/* Error, try to recover */
	kill(getpid(), SIGALRM);
	break;

      case 0:
	/* Child process */
	end = getMilliTime() + deltaMilli;
	do {
	  ticks = end - getMilliTime();
	  if (ticks > 1100) {		/* +100 is arbitrary */
	    sleep((int) (ticks / 1000))
	  }
	} while (ticks > 0);
	kill (getppid(), SIGALRM)
	_exit(0);
    }
#endif

#if defined(HAVE_ALARM) && !defined(ALARM_DONE)
#define ALARM_DONE
    alarm(deltaMilli / 1000);
#endif

#if defined(ALARM_DONE)
#undef ALARM_DONE
#else
    /* Cannot do anything better than this */
    kill(getpid(), SIGALRM);
#endif
  }
}

For DJGPP, the setitimer system is used (though using
alarm() led to the same problem).
setSignalHandler either uses signal() or the posix signal functions
(sigemptyset/sigaction); again, tried both with the same results.

> And what is the value of the argument to `relinquish' in this
> particular test?
> 
> This sounds like some problem with how the signal handler was set, or
> what it did.  The above would be the expected result if the signal
> handler for SIGALRM was reset to SIG_DFLT.  Can you add some debugging
> print-out to the signal handler that will show whether it is called or
> not?
I'll check.

> Oh, btw: this run on Windows, right?  On Windows, you need to make
Yes.
> sure the DOS box where the program is running never goes int
> background, because Windows almost stops delivering timer tick
> interrupts to background programs (they get something like 10% of
> ticks).
No, was foreground all the time.
I did check the libc manual, Eli ;-P

> OK. But since we're dealing with an interpreted language, I figured trying
> to debug something would prove difficult even without the timer stuff.
> Why?  I routinely run Emacs (another interpreter) under GDB with no
> visible problems.  I even debug GDB itself with GDB, although it has a
> command-line interpreter built into it.
My bad - since it's byte-compiled, there's no problem stepping through the
routines that ibnterpret those bytecodes; somehow I thought I'd be stepping
through machine code that had been generated at run-time (which wouldn't
have debug info).
I'll build a stabbed version later and see what the debugger says.