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 14:53:04 +0100
Message-ID:	<NEBBIOJNGMKPNOBKHCGHIEODCAAA.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.1010121150237.16311F-100000@is>
Importance:	Normal
X-MimeOLE:	Produced By Microsoft MimeOLE V5.50.4133.2400
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id IAA28164
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

> It shouldn't.  Moreover, I think I've seen a signal interrupt 
> `__dpmi_yield' many times, with no visible problems.

> First, make sure the problem persists with stock v2.03 library.  If it 
I'm using the stock 2.03 library.

> does, I'd first suspect that Smalltalk's `relinquish' isn't as innocent 
> as your description suggests; perhaps it does something which in the DJGPP 
> case disables or interferes with the signal handling machinery.
Hmmm. relinquish itself is pretty innocent:

void
relinquish(usecs)
     int usecs;
{
/* Please feel free to make this more accurate for your operating system
 * and send me the changes.
 */
#if defined(WIN32)
  Sleep((usecs + 999) / 1000);
#else
#ifdef HAVE_SELECT
  struct timeval time;
  time.tv_sec = usecs / 1000000;
  time.tv_usec = usecs % 1000000;

  select(0, NULL, NULL, NULL, &time);
#endif
#endif
}

I first added

#elif defined(__DJGPP__)
  sleep((usecs + 999) / 1000);

and finally

#elif defined(__DJGPP__)
  /* Do nothing; otherwise, breakage ensues */

which worked. I just tried usleep(usecs) (had forgotten about that
function); that works too, so I'll use that.

But maybe some other code makes this evil; what kind of thing would
screw up the signals?
When the SIGALRM killed the program, this resulted in:

"Major GC flip... done, used space = 53%"
GNU Smalltalk Ready

Execution begins...
4
Exiting due to signal SIGALRM
Exception 78 at eip=0004b630
eax=00000000 ebx=0000002f ecx=00000000 edx=0000000d esi=00000000 edi=000f7728
ebp=000f76fc esp=000f76f0 program=H:\TMP\SOURCE\SMALLT~1.5\GST.EXE
cs: sel=00a7  base=84026000  limit=ffff8fff
ds: sel=00af  base=84026000  limit=ffff8fff
es: sel=00b7  base=84026000  limit=ffff8fff
fs: sel=0087  base=0000a740  limit=0000ffff
gs: sel=00bf  base=00000000  limit=0010ffff
ss: sel=00af  base=84026000  limit=ffff8fff
App stack: [000f8450..00078450]  Exceptn stack: [00078380..00076440]

Call frame traceback EIPs:
  0x0004b630 ___dpmi_simulate_real_mode_interrupt+48
  0x0004210c ___dpmi_yield+44
  0x0003d2e9 _sleep+25 (or _select, if that was used)
  0x000187db _relinquish+43
  0x00010cf5 _emptyContextPool+8205

> As another data point, does a simple test program which sets up a timer 
> and then calls `select' to wait forever succeeds to DTRT?
I tried a simple program that set a 3-second alarm using setitimer, then
slept for 10 seconds. While it did take slightly longer than 3 seconds,
it did fire properly; no SIGALRM exit.

> Also, make sure you do NOT run this under a debugger.  The DJGPP debug 
> support doesn't work reliably when timers fire, this is a known bug for 
> which there's no solution or work-around yet.  If you did run this under 
> a debugger, chances are your observations have very little to do with the 
> actual problems.
OK. But since we're dealing with an interpreted language, I figured trying
to debug something would prove difficult even without the timer stuff.

- Raw text -