Re: Signals and the such-like

[Christopher Faylor <cgf at redhat dot com>]

On Thu, Jul 25, 2002 at 09:41:53PM +0100, Conrad Scott wrote:
>[Sorry: Long email]
>
>About a week ago I discovered a race condition in the UNIX domain
>socket emulation in cygwin.  I've got a patch for this that works
>(and fixes several other small problems) bar one *minor* issue and
>since I'm out of ideas, I hope someone else out there has got some
>advice for me (even if it's only "don't do that!").
>
>Here goes.  I've put together a new UNIX domain handshake
>protocol, but somewhere it's got to pause long enough for the
>server to pick up the client's half of the protocol, since with a
>socket a client can get connection, write some data and close the
>socket before the server has accepted the connection (the
>connection's just sitting on the pending queue).
>
>So, I've got a piece of code in the fhandler_socket::close method
>that only closes the client's secret event once the client has
>received the server's okay signal *or* a (Unix) signal arrives
>*or* the server closes its end of the connection (i.e. the server
>exits w/o ever accepting the connection).

What is an "ok" signal in this context?  Are you introducing handshaking
between two processes that wasn't there originally?  That sounds
dangerous.  It sounds like you will have permission problems to worry
about.

>This is all fine and dandy except for two situations: if the
>client receives an unhandled signal that should cause it to die
>*or* if the client exits w/o closing the socket.  At this point,
>if the server is blocked itself and not accepting the connection,
>the client will not exit and can't be ctrl-c'd either.   The
>problems in the two situations are caused by the same issue:
>
>*) If the client receives an unhandled signal, e.g. SIGINT, the
>do_exit function is called, which then calls close_all_files.  But
>it does this w/o setting the 'signal_arrived' event, so none of
>the events are set that the fhandler_socket::close method is
>waiting on (at least, not in the particular circumstances
>mentioned here).

Actually, this is by design.  The process is exiting.  It's trying to
exit quickly and not wake up any sleeping threads.  This reduces, but
does not eliminate, potential races or deadlocks.

If you set signal_arrived, you're going to have two threads operating at
the same time with unpredictable results.

We try hard to avoid situations where we rely on cygwin processes
behaving predictably on exit.  In your scenario, it sounds like you
would have a hang situation if a process is terminated from the task
manager.

cgf