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: <032101c234e2$ccb12590$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> <007101c2342b$ca598e20$6132bc3e AT BABEL> <20020726015401 DOT GA11868 AT redhat DOT com>
Subject: Re: Signals and the such-like
Date: Fri, 26 Jul 2002 21:27:01 +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:
> I was about to reluctantly say ok and make the "exit_state"
variable
> in do_exit a global but then I started to wonder if this isn't
> a problem with every call to close_all_files.  There are a
couple of
> them outside of the call to do_exit.  One is in spawn_guts and
one
> is on vfork.  I don't think either of those should hang either,
> should they?

Seems I was being a bit parochial: the code I've got can only
block on the last close (system wide) of a UNIX domain socket, so
the only close_all_files that I was seeing a problem with was the
one in do_exit.  But if blocking on close is a problem, then it
ought to be fixed everywhere.

I don't know enough about the two bits of code you mention (I'll
go have a look now) but a global flag is less appealing outside of
exit code (as it could be seen by code that isn't meant to be
affected --- in other threads?).  If this is a problem, a solution
might be a block/don't block flag to fhandler::close.  Pretty
mechanical to add but tedious.  Would you accept a patch that did
this?

I'm just putting together a patch for my UNIX domain socket
changes and if there's no resolution to this issue, I'll just
leave (for the moment) the possibility of a block on close ---
it'll probably never happen in practice (famous last words?) and
the user can always kill the relevant server anyhow, which must
itself be having problems to block up the clients in this way.

Cheers for the moment,

// Conrad