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