Mail Archives: cygwin-developers/2002/07/25/18:13:48
On Thu, Jul 25, 2002 at 10:57:55PM +0100, Conrad Scott wrote:
>"Christopher Faylor" <cgf AT redhat DOT 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
- Raw text -