Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Date: Thu, 25 Jul 2002 18:13:56 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: Signals and the such-like
Message-ID: <20020725221356.GB8349@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <00af01c2341b$b6138890$6132bc3e AT BABEL> <20020725205402 DOT GC6611 AT redhat DOT com> <001101c23426$55177f00$6132bc3e AT BABEL>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <001101c23426$55177f00$6132bc3e@BABEL>
User-Agent: Mutt/1.3.23.1i

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