delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2000/02/03/10:38:53

Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Message-ID: <779F20BCCE5AD31186A50008C75D99791716D2@SILLDN_MAIL1>
From: "Fifer, Eric" <EFifer AT sanwaint DOT com>
To: cygwin AT sourceware DOT cygnus DOT com
Subject: call_handler, interrupt_now and interruptible
Date: Thu, 3 Feb 2000 15:40:36 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)

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 AT sourceware DOT cygnus DOT com

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019