Fifo blocking and performance issues

Fifo blocking and performance issues

[bob]

We are continuing our long drawn out effort to port the SIMPL toolkit 
(http://www.icanprogram.com/simpl) to the Cygwin platform.     For a long time 
we were unable to proceed due to issues with the fifo implementation under 
Cygwin.   These issues have largely been addressed in more recent Cygwin 
releases.    However, some curious and frustrating issues remain.

The most difficult remaining issue concerns the difference in blocking behavior 
of Cygwin RDWR fifos versus their Linux counterparts.   Under Linux you can 
open a fifo as RDWR and have it safely and conveniently block on the subsequent 
read if there is no information on the fifo (or no other partner on the other 
end).     Under Cygwin RDWR fifos block on the open call until the partner 
shows up.      We hacked around this "problem" by opening RDWR+O_NONBLOCK 
on Cygwin and then surrounding our reads with a selec()t on the file 
descriptor.    While this hack works the performance under Cygwin is orders of 
magnitude slower than the equivalent Linux performance.

Any suggestions on how we can achieve a higher performance blocking read on a 
Cygwin RDWR fifo?

The second issue is related.    The other end of these RDWR fifos is typically 
open WRONLY.     Most of the time the open does not block but occasionally we 
have found a condition where this open does block.    Early experimentation 
points to a condition whereby the fifo was previously opened and  written to by 
another process and where that process continues to have an open file 
descriptor.

Once again are there any good suggestions on how to avoid blocking on a 
multiplexed WRONLY fifo open?

The final issue concerns the select() hack described above.    When running our 
benchmark test which repeatly composes and sends a message,  we notice that 
occasionally (once every 50 times or so) the select releases but the 
subsequent read fails with errno 11 (resource temporarily unavailable).    If 
this error is "ignored" and the read retried things seem to work.

Any ideas?

Thanks in advance for your help.

bob

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Fifo blocking and performance issues

[Christopher Faylor]

On Tue, Oct 02, 2012 at 03:15:37PM -0400, bob wrote:
>Any suggestions on how we can achieve a higher performance blocking read on a 
>Cygwin RDWR fifo?

As always, if you can provide test cases of bugs we will endeavor to fix problems.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[PATCH] Re: Fifo blocking and performance issues

[Gregory M. Turner]

[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]

On 10/2/2012 1:19 PM, Christopher Faylor wrote:
> On Tue, Oct 02, 2012 at 03:15:37PM -0400, bob wrote:
>> Any suggestions on how we can achieve a higher performance blocking read on a
>> Cygwin RDWR fifo?
>
> As always, if you can provide test cases of bugs we will endeavor to fix problems.

I didn't think the RDWR fifo's worked at all -- they certainly don't if 
you create them via bash.

I have a patch for this but there are some problems with it.

I've enclosed the work-in-progress patch, feel free to give it a try and 
see if that changes anything (you'll need to rebuild your cygwin1.dll 
from cvs, the instructions are in the cygwin FAQ).

If people have any ideas on how to improve on what I did here I'd love 
to hear from them.  My current thinking is that to really fix cygwin 
fifo's we need to divorce cygwin's fifo handles from the win32 named 
pipe handles used to implement them.

No promises that I ever actually get around to doing this -- but to 
/really/ fix cygwin named pipes, I'm leaning towards the following approach:

  o create a fhandler_pipe_base class that implements pipes using
    MailSlots instead of win32 named pipes; it should be a
    descendant of fhandler_overlapped_base so that we have enough
    freedom to implement the correct blocking semantics

  o make fhandler_pipe and fhandler_fifo into trivial superclasses
    of fhandler_pipe_base; they should only need to override
    ::open and, I think, only need to override the naming
    convention applied to the MailSlot objects.

But the above is bikeshedding based on what I learned mucking around 
with the existing implementation.  It's a decent amount of work to 
actually implement that plan.

-gmt


[-- Attachment #2: cygwin-1.7.pre17-duplex-fifo-support.patch --]
[-- Type: text/plain, Size: 11013 bytes --]

Index: winsup/cygwin/fhandler.h
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/fhandler.h,v
retrieving revision 1.474
diff -u -p -r1.474 fhandler.h
--- winsup/cygwin/fhandler.h	16 Aug 2012 23:34:43 -0000	1.474
+++ winsup/cygwin/fhandler.h	1 Oct 2012 02:31:07 -0000
@@ -731,10 +731,18 @@ class fhandler_fifo: public fhandler_bas
 {
   HANDLE read_ready;
   HANDLE write_ready;
+  HANDLE duplex_write_handle;
   bool wait (HANDLE) __attribute__ ((regparm (2)));
   char *fifo_name (char *, const char *) __attribute__ ((regparm (2)));
 public:
   fhandler_fifo ();
+  bool is_duplex() { return (duplex_write_handle != INVALID_HANDLE_VALUE); }
+  HANDLE& get_output_handle ()
+    {
+      return is_duplex() ? 
+               duplex_write_handle :
+               fhandler_base_overlapped::get_output_handle ();
+    }
   int open (int, mode_t);
   int close ();
   int dup (fhandler_base *child, int);
Index: winsup/cygwin/fhandler_fifo.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/fhandler_fifo.cc,v
retrieving revision 1.55
diff -u -p -r1.55 fhandler_fifo.cc
--- winsup/cygwin/fhandler_fifo.cc	17 Jun 2012 20:50:24 -0000	1.55
+++ winsup/cygwin/fhandler_fifo.cc	1 Oct 2012 02:31:07 -0000
@@ -26,7 +26,8 @@
 
 fhandler_fifo::fhandler_fifo ():
   fhandler_base_overlapped (),
-  read_ready (NULL), write_ready (NULL)
+  read_ready (NULL), write_ready (NULL),
+  duplex_write_handle(INVALID_HANDLE_VALUE)
 {
   max_atomic_write = DEFAULT_PIPEBUFSIZE;
   need_fork_fixup (true);
@@ -34,8 +35,6 @@ fhandler_fifo::fhandler_fifo ():
 
 #define fnevent(w) fifo_name (npbuf, w "-event")
 #define fnpipe() fifo_name (npbuf, "fifo")
-#define create_pipe(r, w) \
-  fhandler_pipe::create (sa_buf, (r), (w), 0, fnpipe (), open_mode)
 
 char *
 fhandler_fifo::fifo_name (char *buf, const char *what)
@@ -81,112 +80,137 @@ fhandler_fifo::open (int flags, mode_t)
     error_errno_set,
     error_set_errno
   } res;
-  bool reader, writer, duplexer;
   DWORD open_mode = FILE_FLAG_OVERLAPPED;
 
-  /* Determine what we're doing with this fhandler: reading, writing, both */
-  switch (flags & O_ACCMODE)
-    {
-    case O_RDONLY:
-      reader = true;
-      writer = false;
-      duplexer = false;
-      break;
-    case O_WRONLY:
-      writer = true;
-      reader = false;
-      duplexer = false;
-      break;
-    case O_RDWR:
-      open_mode |= PIPE_ACCESS_DUPLEX;
-      reader = true;
-      writer = false;
-      duplexer = true;
-      break;
-    default:
-      set_errno (EINVAL);
-      res = error_errno_set;
-      goto out;
-    }
-
-  debug_only_printf ("reader %d, writer %d, duplexer %d", reader, writer, duplexer);
   set_flags (flags);
   char char_sa_buf[1024];
   LPSECURITY_ATTRIBUTES sa_buf;
   sa_buf = sec_user_cloexec (flags & O_CLOEXEC, (PSECURITY_ATTRIBUTES) char_sa_buf,
 		      cygheap->user.sid());
   char npbuf[MAX_PATH];
+  int err;
 
   /* Create control events for this named pipe */
-  if (!(read_ready = CreateEvent (sa_buf, duplexer, false, fnevent ("r"))))
+  if (!(read_ready = CreateEvent (sa_buf, false, false, fnevent ("r"))))
     {
-      debug_printf ("CreatEvent for %s failed, %E", npbuf);
+      debug_printf ("CreateEvent for %s failed, %E", npbuf);
       res = error_set_errno;
       goto out;
     }
   if (!(write_ready = CreateEvent (sa_buf, false, false, fnevent ("w"))))
     {
-      debug_printf ("CreatEvent for %s failed, %E", npbuf);
-      res = error_set_errno;
-      goto out;
-    }
-
-  /* If we're reading, create the pipe, signal that we're ready and wait for
-     a writer.
-     FIXME: Probably need to special case O_RDWR case.  */
-  if (!reader)
-    /* We are not a reader */;
-  else if (create_pipe (&get_io_handle (), NULL))
-    {
-      debug_printf ("create of reader failed");
-      res = error_set_errno;
-      goto out;
-    }
-  else if (!arm (read_ready))
-    {
+      debug_printf ("CreateEvent for %s failed, %E", npbuf);
       res = error_set_errno;
       goto out;
     }
-  else if (!duplexer && !wait (write_ready))
-    {
-      res = error_errno_set;
-      goto out;
-    }
-
-  /* If we're writing, it's a little tricky since it is possible that
-     we're attempting to open the other end of a pipe which is already
-     connected.  In that case, we detect ERROR_PIPE_BUSY, reset the
-     read_ready event and wait for the reader to allow us to connect
-     by signalling read_ready.
 
-     Once the pipe has been set up, we signal write_ready.  */
-  if (writer)
+  /* Determine what we're doing with this fhandler: reading, writing, both */
+  switch (flags & O_ACCMODE)
     {
-      int err;
+    case O_WRONLY:
+      /* After waiting for read_ready to signal, but before
+         ::create completes the connection process, it's possible
+         for another writer to sneak in and get connected, in
+         which case, we receive ERROR_PIPE_BUSY.  If this occurs,
+         we reset the read_ready event, wait for another signal,
+         and try again.
+
+         Once the pipe has been connected, we signal write_ready,
+         in order to wake up the reader, who will block pending
+         this notification. */
       while (1)
-	if (!wait (read_ready))
-	  {
-	    res = error_errno_set;
-	    goto out;
-	  }
-	else if ((err = create_pipe (NULL, &get_io_handle ())) == 0)
-	  break;
-	else if (err == ERROR_PIPE_BUSY)
-	  {
-	    debug_only_printf ("pipe busy");
-	    ResetEvent (read_ready);
-	  }
-	else
-	  {
-	    debug_printf ("create of writer failed");
-	    res = error_set_errno;
-	    goto out;
-	  }
+        if (!wait (read_ready))
+          {
+            res = error_errno_set;
+            debug_printf("error waiting for read_ready: %d", res);
+            goto out;
+          }
+        else if ((err = fhandler_pipe::create (sa_buf, NULL, &get_io_handle(),
+                                               0, fnpipe (), open_mode)) == 0)
+          break; /* from the while(1) loop */
+        else if (err == ERROR_PIPE_BUSY)
+          debug_only_printf ("write pipe-end busy after signal; retrying");
+        else
+          {
+            res = error_set_errno;
+            debug_printf ("create of writer failed: error %d", res);
+            goto out;
+          }
+
       if (!arm (write_ready))
-	{
-	  res = error_set_errno;
-	  goto out;
-	}
+        {
+          res = error_set_errno;
+          debug_printf("!arm (write_ready): error %d", res);
+          goto out;
+        }
+      else
+        break;
+    case O_RDONLY:
+      /* If we're reading, create the pipe, signal that we're ready and wait for
+         a writer. */
+      if (fhandler_pipe::create (sa_buf, &get_io_handle(), NULL,
+                                      0, fnpipe (), open_mode))
+        {
+          res = error_set_errno;
+          debug_printf ("create of reader pipe failed: error %d", res);
+          goto out;
+        }
+      else if (!arm (read_ready))
+        {
+          res = error_set_errno;
+          debug_printf("!arm (read_ready): error %d", res);
+          goto out;
+        }
+      else if (!wait (write_ready))
+        {
+          res = error_errno_set;
+          debug_printf("!wait (write_ready): error %d", res);
+          goto out;
+        }
+      else
+        break;
+    case O_RDWR:
+      /* FIXME: We have a serious problem if we get ERROR_PIPE_BUSY here, because we
+         aren't supposed to block.  POSIX is silent about this, but blocking really
+         seems bad (is some handsome virtual fireman coming to rescue us?)
+
+         This is not academic: we can create just one duplex instance before all
+         subsequent attempts will fail this way or block forever.
+
+         I'm afraid we may need to gut-rehab much of this class to get things to
+         really work right, even though they come tantalizingly close as-is. */
+      if ((err = fhandler_pipe::create (sa_buf, &get_io_handle(), &duplex_write_handle,
+                                        0, fnpipe (), open_mode )) != 0)
+        {
+          res = error_set_errno;
+          debug_printf("pipe create failure during duplex fifo open: error %d", res);
+          goto out;
+        }
+      else
+        /* JUSTIFICATION
+
+           Let's dry-run the 2x-half-duplex reader/writer scenario: someone forks,
+           opens a read-end, and then opens a write-end after a significant delay.
+           To wit:
+
+           o The reader creates its win32 pipe handle, triggers read_ready, and blocks
+             pending write_ready.
+
+           o Along comes the writer, who waits for read-ready.  However, read-ready
+             is already triggered, so now it automatically untriggers, and the writer
+             thread immediately continues (the reader remains blocked).
+
+           o The writer triggers write_ready, which the reader is already waiting
+             for; write_ready also becomes untriggered and both threads are awake.
+
+           That's it -- they both call setup_overlapped() and immediately return. 
+           As of now, we approximate this state of affairs perfectly; there's nothing
+           more for us to do (except fix the bugs in the above approach :P). */
+        break;
+    default:
+      set_errno (EINVAL);
+      res = error_errno_set;
+      goto out;
     }
 
   /* If setup_overlapped() succeeds (and why wouldn't it?) we are all set. */
@@ -215,6 +239,8 @@ out:
 	}
       if (get_io_handle ())
 	CloseHandle (get_io_handle ());
+      if (is_duplex())
+        CloseHandle (duplex_write_handle);
     }
   debug_printf ("res %d", res);
   return res == success;
@@ -322,6 +348,8 @@ fhandler_fifo::close ()
 {
   CloseHandle (read_ready);
   CloseHandle (write_ready);
+  if (is_duplex())
+    CloseHandle (duplex_write_handle);
   return fhandler_base::close ();
 }
 
@@ -351,6 +379,17 @@ fhandler_fifo::dup (fhandler_base *child
       __seterrno ();
       return -1;
     }
+  if (is_duplex() &&
+      !DuplicateHandle (GetCurrentProcess(), duplex_write_handle,
+                        GetCurrentProcess(), &fhf->duplex_write_handle,
+                        0, true, DUPLICATE_SAME_ACCESS))
+    {
+      CloseHandle (fhf->read_ready);
+      CloseHandle (fhf->write_ready);
+      fhf->close();
+      __seterrno();
+      return -1;
+    }
   return 0;
 }
 
@@ -360,6 +399,8 @@ fhandler_fifo::fixup_after_fork (HANDLE 
   fhandler_base_overlapped::fixup_after_fork (parent);
   fork_fixup (parent, read_ready, "read_ready");
   fork_fixup (parent, write_ready, "write_ready");
+  if (is_duplex())
+    fork_fixup (parent, duplex_write_handle, "duplex_write_handle");
 }
 
 void
@@ -368,4 +409,6 @@ fhandler_fifo::set_close_on_exec (bool v
   fhandler_base::set_close_on_exec (val);
   set_no_inheritance (read_ready, val);
   set_no_inheritance (write_ready, val);
+  if (is_duplex())
+    set_no_inheritance (duplex_write_handle, val);
 }


[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [PATCH] Re: Fifo blocking and performance issues

[Christopher Faylor]

On Tue, Oct 02, 2012 at 01:45:08PM -0700, Gregory M. Turner wrote:
>On 10/2/2012 1:19 PM, Christopher Faylor wrote:
>> On Tue, Oct 02, 2012 at 03:15:37PM -0400, bob wrote:
>>> Any suggestions on how we can achieve a higher performance blocking read on a
>>> Cygwin RDWR fifo?
>>
>> As always, if you can provide test cases of bugs we will endeavor to fix problems.
>
>I didn't think the RDWR fifo's worked at all -- they certainly don't if 
>you create them via bash.

If you want to submit an assignment I'll be happy to look at the patch.
It is too big to be included without an assignment.  See:

http://cygwin.com/contrib.html

FYI, a quick scan seems to show that you've pretty much undone a lot of
what I've recently added for fifos so I don't expect to really be too
keen on applying the patch.  But, I don't want to spend too much time
inspecting a change which can't yet be applied.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [PATCH] Re: Fifo blocking and performance issues

[Gregory M. Turner]

On 10/2/2012 5:55 PM, Christopher Faylor wrote:
> On Tue, Oct 02, 2012 at 01:45:08PM -0700, Gregory M. Turner wrote:
>> On 10/2/2012 1:19 PM, Christopher Faylor wrote:
>>> On Tue, Oct 02, 2012 at 03:15:37PM -0400, bob wrote:
>>>> Any suggestions on how we can achieve a higher performance blocking read on a
>>>> Cygwin RDWR fifo?
>>>
>>> As always, if you can provide test cases of bugs we will endeavor to fix problems.
>>
>> I didn't think the RDWR fifo's worked at all -- they certainly don't if
>> you create them via bash.
>
> If you want to submit an assignment I'll be happy to look at the patch.
> It is too big to be included without an assignment.  See:
>
> http://cygwin.com/contrib.html
>
> FYI, a quick scan seems to show that you've pretty much undone a lot of
> what I've recently added for fifos so I don't expect to really be too
> keen on applying the patch.  But, I don't want to spend too much time
> inspecting a change which can't yet be applied.

Yeah, I'm aware of this; I'd be happy to assign -- I'm always easy when 
it comes to IP stuff.  FTR, that doesn't mean I expect this patch to go 
in or even be looked at; I'd just like for it to be a non-issue in the 
future.

Is your tree available somewhere for perusal, Chris?  Or is there some 
way we could get a look at your WIP pipe/fifo deltas?  I'm on 
-developers and -patches if you want to change venues.

I'd definitely be keen to know where that's headed, since it impacts 
some decisions I need to make for my cygwin gentoo work -- plus, I may 
have managed to glean some insight into the limitations of what's in 
cvs... but I obviously shouldn't go much further with it if I'm just 
creating a merge situation or, worse, addressing bugs that you already 
fixed.

-gmt



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Fifo blocking and performance issues

[Earnie Boyd]

On Tue, Oct 2, 2012 at 3:15 PM, bob wrote:
> While this hack works the performance under Cygwin is orders of
> magnitude slower than the equivalent Linux performance.
>
> Any suggestions on how we can achieve a higher performance blocking read on a
> Cygwin RDWR fifo?
>

You expect too much, it is Windows under the hood and no one but
Microsoft can change that performance issue.  Windows alone (meaning
without Cygwin) is orders of magnitude slower than Linux.  Cygwin adds
another layer of slowness just because of the emulation required.  You
might get a tweak or two of milliseconds by modifying some underlying
code but you're not going to get too much more.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [PATCH] Re: Fifo blocking and performance issues

[Christopher Faylor]

On Wed, Oct 03, 2012 at 02:58:55AM -0700, Gregory M. Turner wrote:
>On 10/2/2012 5:55 PM, Christopher Faylor wrote:
>>On Tue, Oct 02, 2012 at 01:45:08PM -0700, Gregory M.  Turner wrote:
>>>On 10/2/2012 1:19 PM, Christopher Faylor wrote:
>>>>On Tue, Oct 02, 2012 at 03:15:37PM -0400, bob wrote:
>>>>>Any suggestions on how we can achieve a higher performance blocking
>>>>>read on a Cygwin RDWR fifo?
>>>>
>>>>As always, if you can provide test cases of bugs we will endeavor to
>>>>fix problems.
>>>
>>>I didn't think the RDWR fifo's worked at all -- they certainly don't if
>>>you create them via bash.
>>
>>If you want to submit an assignment I'll be happy to look at the patch.
>>It is too big to be included without an assignment.  See:
>>
>>http://cygwin.com/contrib.html
>>
>>FYI, a quick scan seems to show that you've pretty much undone a lot of
>>what I've recently added for fifos so I don't expect to really be too
>>keen on applying the patch.  But, I don't want to spend too much time
>>inspecting a change which can't yet be applied.
>
>Yeah, I'm aware of this; I'd be happy to assign -- I'm always easy when
>it comes to IP stuff.  FTR, that doesn't mean I expect this patch to go
>in or even be looked at; I'd just like for it to be a non-issue in the
>future.
>
>Is your tree available somewhere for perusal, Chris?  Or is there some
>way we could get a look at your WIP pipe/fifo deltas?  I'm on
>-developers and -patches if you want to change venues.

Maybe you are misinterpreting "What I've recently added".  I made big
changes to fifo handling in the last couple of Cygwin releases.  That is
what I was referring to.  Otherwise, no, you can't look at my sandbox.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Fifo blocking and performance issues

[Christopher Faylor]

On Wed, Oct 03, 2012 at 08:29:21AM -0400, Earnie Boyd wrote:
>On Tue, Oct 2, 2012 at 3:15 PM, bob wrote:
>>While this hack works the performance under Cygwin is orders of
>>magnitude slower than the equivalent Linux performance.
>>
>>Any suggestions on how we can achieve a higher performance blocking
>>read on a Cygwin RDWR fifo?
>>
>
>You expect too much, it is Windows under the hood and no one but
>Microsoft can change that performance issue.  Windows alone (meaning
>without Cygwin) is orders of magnitude slower than Linux.  Cygwin adds
>another layer of slowness just because of the emulation required.  You
>might get a tweak or two of milliseconds by modifying some underlying
>code but you're not going to get too much more.

But, again, if we are talking about differences in behavior which are
not simply "Linux is faster" then provide a simple test case which works
one way on Linux and another on Cygwin and I'll look into fixing the
problem.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [PATCH] Re: Fifo blocking and performance issues

[Gregory M. Turner]

On 10/3/2012 6:02 AM, Christopher Faylor wrote:
> On Wed, Oct 03, 2012 at 02:58:55AM -0700, Gregory M. Turner wrote:
>> On 10/2/2012 5:55 PM, Christopher Faylor wrote:
>>> FYI, a quick scan seems to show that you've pretty much undone a lot of
>>> what I've recently added for fifos so I don't expect to really be too
>>> keen on applying the patch.  But, I don't want to spend too much time
>>> inspecting a change which can't yet be applied.
>>
>> Yeah, I'm aware of this; I'd be happy to assign -- I'm always easy when
>> it comes to IP stuff.  FTR, that doesn't mean I expect this patch to go
>> in or even be looked at; I'd just like for it to be a non-issue in the
>> future.
>>
>> Is your tree available somewhere for perusal, Chris?  Or is there some
>> way we could get a look at your WIP pipe/fifo deltas?  I'm on
>> -developers and -patches if you want to change venues.
>
> Maybe you are misinterpreting "What I've recently added".> I made big
> changes to fifo handling in the last couple of Cygwin releases.  That is
> what I was referring to.  Otherwise, no, you can't look at my sandbox.

Yep, I thought what you think I thought :)

Unfortunately, with my patch, once the first RDWR handle is created, and 
until it and all of its clones are closed, subsequent attempts to create 
additional non-cloned handles don't work.

The root cause is my patch's use of "platonic" half-duplex win32 pipe 
handles, analogous to pipe2().  Although difficult to "prove" without a 
lot of verbiage, I believe that this can't be solved in that approach 
without changing the way fhandler_fifo coordinates readers and writers. 
  So yeah, the patch probably starts fhandler_fifo down a path that 
would require some sort of significant semantic change.

I used to believe this also proved that the current approach was flawed; 
but after after some alone-time with your comments, cvs commit history, 
and a nerf-brand clue-by-four, I'm feeling a lot more agnostic about 
that... so back to the drawing board, if anywhere; I wouldn't encourage 
you to put much effort into understanding my patch.

Hopefully, though, I'm starting to get what you're trying to do with 
PIPE_ACCESS_DUPLEX.  If I ever have a good enough question about this 
that I can formulate it and press the send button without figuring out 
the answer, I won't hesitate.

-gmt

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple