Re: Signals and the such-like

[Christopher Faylor <cgf at redhat dot com>]

On Thu, Jul 25, 2002 at 10:57:55PM +0100, Conrad Scott wrote:
>"Christopher Faylor" <cgf@redhat.com> wrote:
>On Thu, Jul 25, 2002 at 09:41:53PM +0100, Conrad Scott wrote:
>>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 just what the existing UNIX socket code does: the client
>and server both create (win32) events and wait on the other's
>event.  The events are created with no security (i.e. anyone can
>access them) but with randomly generated names: the idea being
>that a process only knows the name if it can open the UNIX domain
>socket file that contains the secret number.  I've not changed the
>basic idea, just the exact handshaking between the two processes
>to avoid the current race condition.
>
>> >*) 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.
>
>Currently the main thread doesn't wake up: the signal thread at
>this point is running at a higher priority and since it doesn't
>suspend (hopefully) the main thread will never get a chance.

That is the point, however, if the main thread is waiting for
signal_arrived, it does stand the chance of waking up.

>The idea was that setting the 'signal_arrived' event would help
>prevent the signal thread from suspending and thus make it more
>likely that the main thread would never run.  That's not quite
>right of course, since the main thread may well be suspended on
>the event and thus not runnable except for that.

Why not just check if you are running with CurrentThreadId () == sigtid?

However, it still sounds like you have a blocking condition if
the read is happening in another thread.

>I hope that I'm being clear enough here: I think I'm juggling too
>many options in one message to be crystal clear.

I think the CurrentThreadId () == sigtid scenario should accomplish
that.

cgf