From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Fifer, Eric" <EFifer@sanwaint.com>
To: cygwin@sourceware.cygnus.com
Subject: call_handler, interrupt_now and interruptible
Date: Thu, 03 Feb 2000 07:43:00 -0000
Message-id: <779F20BCCE5AD31186A50008C75D99791716D2@SILLDN_MAIL1>
X-SW-Source: 2000-02/msg00024.html

Since I switched over from b20.1 to the development snapshots, I've noticed
a difference in the behavior of signal delivery.

Right now, I can't seem to immediately catch signals while calculations are
going on in a DLL.

This behavior seems to be controlled by call_handler() in exceptions.cc and
in
particular by interruptible():

interruptible (DWORD pc)
{
  DWORD pchigh = pc & 0xf0000000;
  return ((pc >= (DWORD) &__sigfirst) && (pc <= (DWORD) &__siglast)) ||
         !(pchigh == 0xb0000000 || pchigh == 0x70000000 || pchigh ==
0x60000000);
}

The comment in the ChangeLog when this was introduced is:

	Implement new signal-handling scheme which ensures that a program
will
	not be interrupted while in a system or cygwin DLL

Anyways, I added some more debugging to see the value of pc when sending
signals (I'm catching/sending SIGUSR1 in my experiments):

1) Running a busy loop in an EXE:

	pc=4010CD   pchigh=0        sigfirst=6A7CAF03 siglast=6A7CAF95

This is fine.

2) Running a busy loop in a DLL:

	pc=60C81059 pchigh=60000000 sigfirst=6A7CAF03 siglast=6A7CAF95

In this case the SIGUSR1 isn't processed until after the DLL returns.  So
I can't use signal handlers to peer into long running calculations that
happen to be done in a DLL.

3) When paused on a system call in a EXE or DLL:

	pc=77F6825B pchigh=70000000 sigfirst=6A7CAF03 siglast=6A7CAF95

I then experimented by commenting out "pchigh == 0x60000000", and things
work
more like I expect (and as they did under b20.1).  Of course, this goes
against
the intent of the comment.  Anyways, is this dangerous to do?  Is it an
appropriate
fix?  Where are the contents of cx->Eip described (I didn't find anything in
MSDN)?
Is there a way to tell the difference between being in a normal DLL, versus
a 
"system" (what does this mean?) or cygwin DLL?

Thanks in advance.

Eric Fifer

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com