Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Mon, 24 Sep 2001 19:20:23 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Put that in your pipe and...
Message-ID: <20010924192023.A32669@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.21i

I've made a few changes to the way cygwin handles pipes in the last
few days.

They are major enough that I probably shouldn't have included them
in 1.3.4 but I just got sick of seeing people with problems in the
cygwin mailing list.

I basically caved in on my principles and wrote a cygwin-only solution
to the problems.  Previously, I'd held out thinking that there was surely
some way to fix things so that pipe operations between cygwin and non-cygwin
programs would work well.

There were two problems:

1) EOF was not detected by select on Windows 9x owing to the fact
   that closing the write end of a pipe did not trigger a "something
   to read" situation.

2) Multiple readers of one end of a pipe would suffer a race where
   a reader would enter into a non-interruptible read state when
   another process read data from a pipe.

I fixed these by:

1) Creating a named dummy event handle which follows the write end
   of the pipe.  When the write end of the pipe is closed, the
   handle is also closed.  The peek_pipe function in select()
   tries to open this object.  If it succeeds, the write end of
   the pipe exists.  If it fails, the write end of the pipe has
   been closed.

   This method is similar to what happens with ttys.  I hate it.
   It involves polling.  It probably slows down pipe operations.
   But it seems to work.  Note that I only employ this method on
   Windows 9x.

2) Creating a "guard" event for pipe read operations.  peek_pipe
   only returns a true (something is in the pipe) when PeekNamedPipe
   says something is available AND when it has the guard mutex.

Note that the fixes for 2 were dsigned to make "make -j2" work correctly.
I managed to do a "make -j2 clean all" in winsup 733 times without hanging
with these changes.

Anyway, I've been living in Windows 95 for several hours now with these
changes and everything seems to be working.

I'll fire off a snapshot soon so that other people can verify if this
works or not.

cgf