delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1998/06/14/13:44:09

From: cgf AT cygnus DOT com (Christopher Faylor)
Subject: RE: SIGKILL and block_sig_dispatch
14 Jun 1998 13:44:09 -0700 :
Message-ID: <199806142022.QAA11311.cygnus.cygwin32.developers@kramden.cygnus.com>
To: cgf AT cygnus DOT com, sos AT prospect DOT com DOT ru
Cc: cygwin32-developers AT cygnus DOT com

>From: Sergey Okhapkin <sos AT prospect DOT com DOT ru>
>Date: Sun, 14 Jun 1998 21:25:20 +0400
>
>Christopher Faylor wrote:
>> >From your description of the problem, I'm not sure what that would solve.
>> Isn't the key thing to just ensure that WSACleanup is not called?  Sure,
>
>Yes, I want to avoid a bug of WSACleanup().
>
>> you could call do_exit in the context of the signal thread for the specific
>> case of SIGKILL but what happens if there is a signal handler which calls
>> exit() when something like a SIGTERM is received?  From your description,
>> there will be a hang.
>
>Why? 

Ok.  The only thing that needs to be done is to remove WSACleanup from exit,
right?  If that is causing hangs, then that sounds like a good thing to do
if there are no other side effects.

You asked why SIGKILL doesn't just suspend the main thread and call
do_exit().  I don't see what this has to do with WSACleanup.  I thought
that perhaps you were saying that calling do_exit from the signal thread
would avoid this problem somehow in some other way.  If that was the
case, I was pointing out that it is not a foolproof solution since other
signals can also call do_exit indirectly.  You can't just have the
signal thread always call the signal handler directly because that won't
work.

- Raw text -


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