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
Message-ID: <007101c2342b$ca598e20$6132bc3e@BABEL>
From: "Conrad Scott" <Conrad DOT Scott AT dsl DOT pipex DOT com>
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> <20020725221356 DOT GB8349 AT redhat DOT com>
Subject: Re: Signals and the such-like
Date: Thu, 25 Jul 2002 23:37:00 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000

"Christopher Faylor" <cgf AT redhat DOT com> wrote:
> >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.

Yep, that's true.  Okay, ditch one "fine" idea :-)

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

For a moment I thought that was it: but this doesn't catch the
situation where the application is exiting without closing the
socket.  Then the blocking close occurs in the exit code where
signals are being blocked.

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

In the problematic scenario, the main thread is either closing the
socket (and is blocked in close already) *or* the program is
exiting, so this shouldn't be a problem.  If the main thread is
reading from the socket, it would block anyway since the problem
occurs only if the server is tardy about accepting the connection
and so cannot have written any data to the socket.

In all these situations, if the program is exiting, the close
should either not block or should be interruptible.  Currently it
has no idea (in general) that the program is exiting (and so
doesn't know not to block) and signals are being ignored (so it
can't be interrupted).

The best solution so far (from where I'm standing) seems to be a
global "exiting" flag.  Is that too unreasonable?

If it is, I could bung in a timeout but this could cause problems
if a server is *really* slow (i.e. the client will timeout, the
handshake won't occur, and the client message will be rejected).
I could return an error from close, but how many programs ever
test for that?

// Conrad