Signal handling tune up.
Sun Aug 31 20:21:00 GMT 2003
On Sun, Aug 31, 2003 at 04:11:47PM -0400, Pierre A. Humblet wrote:
>At 02:39 PM 8/31/2003 -0400, you wrote:
>>On Sun, Aug 31, 2003 at 11:23:52AM -0400, Pierre A. Humblet wrote:
>>>thanks for your quick response to the ftp crash.
>>It would have been much quicker if I'd clued into the fact that an
>>address like a0dc018 != a0dc01c. It took my 127 attempts at running ftp
>>to finally see what was going on.
>>I can't believe that this hasn't caused problems for other programs.
>>It's a pretty serious problem. Every time I think I've got this fixed
>>another corner case occurs to me which has to be dealt with.
>I had the feeling I had seen mails on gethostbyname before.
>So I suspected it wasn't trivial and I spent the evening on
>other kind of activities !
>>>writev (const int fd, const struct iovec *const iov, const int iovcnt)
>>> sig_dispatch_pending ();
>>> sigframe thisframe (mainthread);
>>>The call to sig_dispatch_pending is meant for the case where
>>>there is a pending signal. Assume there indeed is one.
>>>The call to sig_dispatch_pending will setup an interrupt in sigsave.
>>>The return address on the stack will be the first interruptible return
>>>address above sig_dispatch_pending, i.e. the return address of writev.
>>>The handler will not be entered until writev returns.
>>Ok. I see what you mean but the old code was not actually right either.
>>I wrote a test case (enclosed) which sent a signal to a process running
>>a modified version of cygwin1.dll after the call to sigframe
>>("guaranteed" with the judicious use of Sleep) in sig_dispatch_pending.
>>The 'ouch' wasn't triggered by the either the old or new cygwin code.
>>So, I've checked in new code in sig_dispatch_pending.
>Why would the ouch be triggered? The parent is long dead when
>the child kills its ppid, which by that time is 1.
`a modified version of cygwin1.dll... ("guaranteed" with the judicious
use of Sleep)'
More information about the Cygwin-patches