Re: Signal handling tune up.

[Christopher Faylor <cgf at redhat dot com>]

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)'

cgf