delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1998/06/14/21:18:16

From: sos AT prospect DOT com DOT ru (Sergey Okhapkin)
Subject: RE: SIGKILL and block_sig_dispatch
14 Jun 1998 21:18:16 -0700 :
Message-ID: <01BD9834.A96FCE00.cygnus.cygwin32.developers@sos>
To: "'Christopher Faylor'" <cgf AT cygnus DOT com>
Cc: "cygwin32-developers AT cygnus DOT com" <cygwin32-developers AT cygnus DOT com>

Christopher Faylor wrote:
> 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.
>

We can't remove WSACleanup() till do_exit() is called in a context of main 
thread (we have to terminate blocking winsock call before).

> 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.
>
>

Chris, I never told about SIGKILL! I'm talking about any _unhandled_ 
signal, whose default disposition is to terminate a process. If do_exit() 
will be called in a context of signal thread, we'll not need WSACleanup() - 
ExitProcess() call will make all neccessary cleanup for us.

--
Sergey Okhapkin, http://www.lexa.ru/sos
Moscow, Russia


- Raw text -


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