* Named pipes and multiple writers
@ 2020-03-25 11:11 sten.kristian.ivarsson
2020-03-25 12:44 ` Ken Brown
0 siblings, 1 reply; 30+ messages in thread
From: sten.kristian.ivarsson @ 2020-03-25 11:11 UTC (permalink / raw)
To: cygwin
I'll apologize in advance if something is not appropriate, but this is the
first interaction with this project
We (another open source project) have bumped into some problems using named
pipes with multiple writers
As far as I can see, reading through history, this have been a known issue
for quite some time, but it seems like there have been some attempts to
solve it, e.g. in the branch topic/fifo (by Ken Brown)
I tried to build that branch and also tried to merge related commits to
master and build that, but all without success and I guess the changes need
some background info to understand how to manually incorporate the changes
into later versions of master
Does anyone have any knowledge about if this (topic/fifo branch) is working
and/or if it is somehow planned to make it into the master branch and end up
in a future release ?
Does anyone know of any other attempts to solve this issue ?
Kristian
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Named pipes and multiple writers
2020-03-25 11:11 Named pipes and multiple writers sten.kristian.ivarsson
@ 2020-03-25 12:44 ` Ken Brown
[not found] ` <18be01d602ab$0bbfca30$233f5e90$@gmail.com>
0 siblings, 1 reply; 30+ messages in thread
From: Ken Brown @ 2020-03-25 12:44 UTC (permalink / raw)
To: cygwin
On 3/25/2020 7:11 AM, Kristian Ivarsson via Cygwin wrote:
> I'll apologize in advance if something is not appropriate, but this is the
> first interaction with this project
>
> We (another open source project) have bumped into some problems using named
> pipes with multiple writers
>
> As far as I can see, reading through history, this have been a known issue
> for quite some time, but it seems like there have been some attempts to
> solve it, e.g. in the branch topic/fifo (by Ken Brown)
>
> I tried to build that branch and also tried to merge related commits to
> master and build that, but all without success and I guess the changes need
> some background info to understand how to manually incorporate the changes
> into later versions of master
>
> Does anyone have any knowledge about if this (topic/fifo branch) is working
> and/or if it is somehow planned to make it into the master branch and end up
> in a future release ?
That branch is obsolete. Support for multiple writers was added to Cygwin as of
release 3.1.0.
Ken
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Sv: Named pipes and multiple writers
[not found] ` <18be01d602ab$0bbfca30$233f5e90$@gmail.com>
@ 2020-03-26 14:06 ` Ken Brown
2020-03-26 15:11 ` Ken Brown
2020-03-26 22:01 ` Sv: " sten.kristian.ivarsson
0 siblings, 2 replies; 30+ messages in thread
From: Ken Brown @ 2020-03-26 14:06 UTC (permalink / raw)
To: sten.kristian.ivarsson; +Cc: cygwin
[Let's keep the discussion on the list in case others have suggestions.]
On 3/25/2020 9:41 AM, sten.kristian.ivarsson@gmail.com wrote:
> [snip]
>>> As far as I can see, reading through history, this have been a known
>>> issue for quite some time, but it seems like there have been some
>>> attempts to solve it, e.g. in the branch topic/fifo (by Ken Brown)
>
> [snip]
>>> Does anyone have any knowledge about if this (topic/fifo branch) is
>>> working and/or if it is somehow planned to make it into the master
>>> branch and end up in a future release ?
>
>> That branch is obsolete. Support for multiple writers was added to Cygwin
> as of release 3.1.0.
>
> Ok, thanks, but we're running 3.1.4 (and tested 3.1.5) but do still have
> problems (experiencing ENXIO (No such device or address)) but actually (as
> far as we see) with the 3:rd writer ?
>
> We need to investigate the issue more thoroughly and might get back when we
> have more knowledge
Does the ENXIO come from fhandler_fifo::wait? If so, it's quite possible that
there's a bug involving read_ready in my code.
Ken
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Sv: Named pipes and multiple writers
2020-03-26 14:06 ` Sv: " Ken Brown
@ 2020-03-26 15:11 ` Ken Brown
2020-03-26 16:03 ` Norton Allen
2020-03-26 22:01 ` Sv: " sten.kristian.ivarsson
1 sibling, 1 reply; 30+ messages in thread
From: Ken Brown @ 2020-03-26 15:11 UTC (permalink / raw)
To: cygwin
On 3/26/2020 10:06 AM, Ken Brown via Cygwin wrote:
> [Let's keep the discussion on the list in case others have suggestions.]
>
> On 3/25/2020 9:41 AM, sten.kristian.ivarsson@gmail.com wrote:
>> [snip]
>>>> As far as I can see, reading through history, this have been a known
>>>> issue for quite some time, but it seems like there have been some
>>>> attempts to solve it, e.g. in the branch topic/fifo (by Ken Brown)
>>
>> [snip]
>>>> Does anyone have any knowledge about if this (topic/fifo branch) is
>>>> working and/or if it is somehow planned to make it into the master
>>>> branch and end up in a future release ?
>>
>>> That branch is obsolete. Support for multiple writers was added to Cygwin
>> as of release 3.1.0.
>>
>> Ok, thanks, but we're running 3.1.4 (and tested 3.1.5) but do still have
>> problems (experiencing ENXIO (No such device or address)) but actually (as
>> far as we see) with the 3:rd writer ?
>>
>> We need to investigate the issue more thoroughly and might get back when we
>> have more knowledge
>
> Does the ENXIO come from fhandler_fifo::wait? If so, it's quite possible that
> there's a bug involving read_ready in my code.
BTW, I've been working on adding support for multiple readers. I expect to have
a first cut ready within a week or two. Would you have any use for that? If
so, I could revive the topic/fifo branch and push my patches there for you to test.
Ken
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Sv: Named pipes and multiple writers
2020-03-26 15:11 ` Ken Brown
@ 2020-03-26 16:03 ` Norton Allen
2020-03-26 16:44 ` Ken Brown
0 siblings, 1 reply; 30+ messages in thread
From: Norton Allen @ 2020-03-26 16:03 UTC (permalink / raw)
To: Ken Brown, cygwin
On 3/26/2020 11:11 AM, Ken Brown via Cygwin wrote:
>
> BTW, I've been working on adding support for multiple readers. I
> expect to have a first cut ready within a week or two. Would you have
> any use for that? If so, I could revive the topic/fifo branch and
> push my patches there for you to test.
>
Ken, what are the semantics for multiple readers? Do all readers see the
same data, or is it first come first served or something else?
--
=============================================================
Norton Allen (he/him/his)
Software Engineer
Harvard University School of Engineering and Applied Sciences
12 Oxford St., Link Bldg. (Office 282)
Cambridge, MA 02138
Phone: (617) 998-5553
=============================================================
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Sv: Named pipes and multiple writers
2020-03-26 16:03 ` Norton Allen
@ 2020-03-26 16:44 ` Ken Brown
2020-03-26 17:00 ` Norton Allen
0 siblings, 1 reply; 30+ messages in thread
From: Ken Brown @ 2020-03-26 16:44 UTC (permalink / raw)
To: cygwin
On 3/26/2020 12:03 PM, Norton Allen wrote:
> On 3/26/2020 11:11 AM, Ken Brown via Cygwin wrote:
>>
>> BTW, I've been working on adding support for multiple readers. I expect to
>> have a first cut ready within a week or two. Would you have any use for
>> that? If so, I could revive the topic/fifo branch and push my patches there
>> for you to test.
>>
>
> Ken, what are the semantics for multiple readers? Do all readers see the same
> data, or is it first come first served or something else?
It's first come, first served. If two readers attempt to read simultaneously,
it's possible that one will get some of the available input and the other will
get some more.
The only use case for multiple readers that I've come across of is Midnight
Commander running under tcsh. I didn't dig into the code enough to know why
they do it, or why only under tcsh. See
https://sourceware.org/pipermail/cygwin/2019-December/243317.html
and
https://cygwin.com/pipermail/cygwin-apps/2019-December/039777.html
That's what got me interested in this. It would be nice to know if there are
other use cases.
Ken
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Sv: Named pipes and multiple writers
2020-03-26 16:44 ` Ken Brown
@ 2020-03-26 17:00 ` Norton Allen
0 siblings, 0 replies; 30+ messages in thread
From: Norton Allen @ 2020-03-26 17:00 UTC (permalink / raw)
To: Ken Brown, cygwin
On 3/26/2020 12:44 PM, Ken Brown via Cygwin wrote:
> On 3/26/2020 12:03 PM, Norton Allen wrote:
>> On 3/26/2020 11:11 AM, Ken Brown via Cygwin wrote:
>>>
>>> BTW, I've been working on adding support for multiple readers. I
>>> expect to have a first cut ready within a week or two. Would you
>>> have any use for that? If so, I could revive the topic/fifo branch
>>> and push my patches there for you to test.
>>>
>>
>> Ken, what are the semantics for multiple readers? Do all readers see
>> the same data, or is it first come first served or something else?
>
> It's first come, first served. If two readers attempt to read
> simultaneously, it's possible that one will get some of the available
> input and the other will get some more.
>
> The only use case for multiple readers that I've come across of is
> Midnight Commander running under tcsh. I didn't dig into the code
> enough to know why they do it, or why only under tcsh. See
>
> https://sourceware.org/pipermail/cygwin/2019-December/243317.html
>
> and
>
> https://cygwin.com/pipermail/cygwin-apps/2019-December/039777.html
>
> That's what got me interested in this. It would be nice to know if
> there are other use cases.
>
I suppose it could be used as a simple approach to deploying jobs to
worker processes, provided a process could guarantee that it received
enough information to define a job and not more than one. I guess if the
job definition were fixed length that could work.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Sv: Sv: Named pipes and multiple writers
2020-03-26 14:06 ` Sv: " Ken Brown
2020-03-26 15:11 ` Ken Brown
@ 2020-03-26 22:01 ` sten.kristian.ivarsson
2020-03-26 22:39 ` Ken Brown
1 sibling, 1 reply; 30+ messages in thread
From: sten.kristian.ivarsson @ 2020-03-26 22:01 UTC (permalink / raw)
To: 'Ken Brown'; +Cc: 'cygwin'
>> [snip]
>>>> As far as I can see, reading through history, this have been a known
>>>> issue for quite some time, but it seems like there have been some
>>>> attempts to solve it, e.g. in the branch topic/fifo (by Ken Brown)
>>
>> [snip]
>>>> Does anyone have any knowledge about if this (topic/fifo branch) is
>>>> working and/or if it is somehow planned to make it into the master
>>>> branch and end up in a future release ?
>>
>>> That branch is obsolete. Support for multiple writers was added to
>>> Cygwin
>> as of release 3.1.0.
>>
>> Ok, thanks, but we're running 3.1.4 (and tested 3.1.5) but do still
>> have problems (experiencing ENXIO (No such device or address)) but
>> actually (as far as we see) with the 3:rd writer ?
>>
>> We need to investigate the issue more thoroughly and might get back
>> when we have more knowledge
>Does the ENXIO come from fhandler_fifo::wait? If so, it's quite possible
that there's a bug involving read_ready in my code.
Our application is a bit complex and I have now narrowed it down
The ENIXIO occurs when parallel child-processes simultaneously using
O_NONBLOCK opening the descriptor. We're sometimes opening it blocking and
sometimes non-blocking and it seems like when the 2:nd non-blocking process
tries to open it gets ENIXIO. The child process open and closes the
fifo-descriptor for writing multiple times. I could provide a code-snippet
to reproduce it if wanted ?
Tnx for showing interest btw
Kristian
>Ken
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Sv: Sv: Named pipes and multiple writers
2020-03-26 22:01 ` Sv: " sten.kristian.ivarsson
@ 2020-03-26 22:39 ` Ken Brown
2020-03-26 23:19 ` Ken Brown
0 siblings, 1 reply; 30+ messages in thread
From: Ken Brown @ 2020-03-26 22:39 UTC (permalink / raw)
To: sten.kristian.ivarsson; +Cc: 'cygwin'
On 3/26/2020 6:01 PM, sten.kristian.ivarsson@gmail.com wrote:
> The ENIXIO occurs when parallel child-processes simultaneously using
> O_NONBLOCK opening the descriptor.
This is consistent with my guess that the error is generated by
fhandler_fifo::wait. I have a feeling that read_ready should have been created
as a manual-reset event, and that more care is needed to make sure it's set when
it should be.
> I could provide a code-snippet
> to reproduce it if wanted ?
Yes, please!
Ken
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Sv: Sv: Named pipes and multiple writers
2020-03-26 22:39 ` Ken Brown
@ 2020-03-26 23:19 ` Ken Brown
2020-03-27 13:10 ` Ken Brown
0 siblings, 1 reply; 30+ messages in thread
From: Ken Brown @ 2020-03-26 23:19 UTC (permalink / raw)
To: sten.kristian.ivarsson; +Cc: 'cygwin'
[-- Attachment #1: Type: text/plain, Size: 683 bytes --]
On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote:
> On 3/26/2020 6:01 PM, sten.kristian.ivarsson@gmail.com wrote:
>> The ENIXIO occurs when parallel child-processes simultaneously using
>> O_NONBLOCK opening the descriptor.
>
> This is consistent with my guess that the error is generated by
> fhandler_fifo::wait. I have a feeling that read_ready should have been created
> as a manual-reset event, and that more care is needed to make sure it's set when
> it should be.
>
>> I could provide a code-snippet
>> to reproduce it if wanted ?
>
> Yes, please!
That might not be necessary. If you're able to build the git repo master
branch, please try the attached patch.
Ken
[-- Attachment #2: 0001-Cygwin-FIFO-make-read_ready-a-manual-reset-event.patch --]
[-- Type: text/plain, Size: 1344 bytes --]
From 279591d91a13616957964256e02344a627b6f558 Mon Sep 17 00:00:00 2001
From: Ken Brown <kbrown@cornell.edu>
Date: Thu, 26 Mar 2020 19:02:16 -0400
Subject: [PATCH] Cygwin: FIFO: make read_ready a manual-reset event
If a FIFO is open for reading and an attempt is made to open it for
writing with O_NONBLOCK, read_ready must be set in order for open to
succeed. When read_ready was an auto-reset event, there was a brief
period when read_ready was not set set after a writer opened. If a
second writer attempted to open the FIFO with O_NONBLOCK during this
period, the attempt would fail.
Addresses: https://sourceware.org/pipermail/cygwin/2020-March/244201.html
---
winsup/cygwin/fhandler_fifo.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/winsup/cygwin/fhandler_fifo.cc b/winsup/cygwin/fhandler_fifo.cc
index 19cd0e507..c05161099 100644
--- a/winsup/cygwin/fhandler_fifo.cc
+++ b/winsup/cygwin/fhandler_fifo.cc
@@ -516,7 +516,7 @@ fhandler_fifo::open (int flags, mode_t)
char npbuf[MAX_PATH];
__small_sprintf (npbuf, "r-event.%08x.%016X", get_dev (), get_ino ());
- if (!(read_ready = CreateEvent (sa_buf, false, false, npbuf)))
+ if (!(read_ready = CreateEvent (sa_buf, true, false, npbuf)))
{
debug_printf ("CreateEvent for %s failed, %E", npbuf);
res = error_set_errno;
--
2.21.0
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Sv: Sv: Named pipes and multiple writers
2020-03-26 23:19 ` Ken Brown
@ 2020-03-27 13:10 ` Ken Brown
2020-03-27 14:53 ` Sv: " sten.kristian.ivarsson
0 siblings, 1 reply; 30+ messages in thread
From: Ken Brown @ 2020-03-27 13:10 UTC (permalink / raw)
To: sten.kristian.ivarsson; +Cc: 'cygwin'
[-- Attachment #1: Type: text/plain, Size: 775 bytes --]
On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote:
> On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote:
>> On 3/26/2020 6:01 PM, sten.kristian.ivarsson@gmail.com wrote:
>>> The ENIXIO occurs when parallel child-processes simultaneously using
>>> O_NONBLOCK opening the descriptor.
>>
>> This is consistent with my guess that the error is generated by
>> fhandler_fifo::wait. I have a feeling that read_ready should have been
>> created as a manual-reset event, and that more care is needed to make sure
>> it's set when it should be.
>>
>>> I could provide a code-snippet
>>> to reproduce it if wanted ?
>>
>> Yes, please!
>
> That might not be necessary. If you're able to build the git repo master
> branch, please try the attached patch.
Here's a better patch.
Ken
[-- Attachment #2: 0001-Cygwin-FIFO-fix-a-problem-opening-nonblocking-writer.patch --]
[-- Type: text/plain, Size: 1828 bytes --]
From 3efd5a8cbff8d48b8cf9807070134bb79f591b7d Mon Sep 17 00:00:00 2001
From: Ken Brown <kbrown@cornell.edu>
Date: Thu, 26 Mar 2020 19:02:16 -0400
Subject: [PATCH] Cygwin: FIFO: fix a problem opening nonblocking writers
Make read_ready a manual-reset event. Previously, when it was an
auto-reset event, there was a brief period when read_ready was not set
after a writer opened. An attempt to open a second writer during this
period would fail with ENXIO if O_NONBLOCK was set, even if a reader
was open.
For the same reason, move ResetEvent(read_ready) from
listen_client_thread() to close().
Addresses: https://sourceware.org/pipermail/cygwin/2020-March/244201.html
---
winsup/cygwin/fhandler_fifo.cc | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/winsup/cygwin/fhandler_fifo.cc b/winsup/cygwin/fhandler_fifo.cc
index 19cd0e507..c7e27e883 100644
--- a/winsup/cygwin/fhandler_fifo.cc
+++ b/winsup/cygwin/fhandler_fifo.cc
@@ -463,7 +463,6 @@ fhandler_fifo::listen_client_thread ()
out:
if (evt)
CloseHandle (evt);
- ResetEvent (read_ready);
if (ret < 0)
debug_printf ("exiting with error, %E");
else
@@ -516,7 +515,7 @@ fhandler_fifo::open (int flags, mode_t)
char npbuf[MAX_PATH];
__small_sprintf (npbuf, "r-event.%08x.%016X", get_dev (), get_ino ());
- if (!(read_ready = CreateEvent (sa_buf, false, false, npbuf)))
+ if (!(read_ready = CreateEvent (sa_buf, true, false, npbuf)))
{
debug_printf ("CreateEvent for %s failed, %E", npbuf);
res = error_set_errno;
@@ -1016,6 +1015,8 @@ fhandler_fifo::close ()
handler or another thread. */
fifo_client_unlock ();
int ret = stop_listen_client ();
+ if (reader && read_ready)
+ ResetEvent (read_ready);
if (read_ready)
CloseHandle (read_ready);
if (write_ready)
--
2.21.0
^ permalink raw reply [flat|nested] 30+ messages in thread
* Sv: Sv: Sv: Named pipes and multiple writers
2020-03-27 13:10 ` Ken Brown
@ 2020-03-27 14:53 ` sten.kristian.ivarsson
2020-03-27 22:56 ` Ken Brown
0 siblings, 1 reply; 30+ messages in thread
From: sten.kristian.ivarsson @ 2020-03-27 14:53 UTC (permalink / raw)
To: 'Ken Brown'; +Cc: 'cygwin'
[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]
>On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote:
>> On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote:
>>> On 3/26/2020 6:01 PM, sten.kristian.ivarsson@gmail.com wrote:
>>>> The ENIXIO occurs when parallel child-processes simultaneously using
>>>> O_NONBLOCK opening the descriptor.
>>>
>>> This is consistent with my guess that the error is generated by
>>> fhandler_fifo::wait. I have a feeling that read_ready should have
>>> been created as a manual-reset event, and that more care is needed to
>>> make sure it's set when it should be.
>>>
>>>> I could provide a code-snippet
>>>> to reproduce it if wanted ?
>>>
>>> Yes, please!
>>
>> That might not be necessary. If you're able to build the git repo
>> master branch, please try the attached patch.
>Here's a better patch.
I finally succeeded to build latest master (make is not my favourite tool)
and added the patch, but still no success in my little test-program (see
attachment) when creating a write-file-descriptor with O_NONBLOCK
>Ken
[-- Attachment #2: pipe.cpp --]
[-- Type: text/plain, Size: 1671 bytes --]
#include <cstring>
#include <fcntl.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>
#include <iostream>
#include <string>
namespace
{
auto error(const int error)
{
std::cerr << getpid() << "\terror:\t" << error << '\t' << std::strerror(error) << std::endl;
return error;
}
}
int main()
{
const auto name{"/tmp/my_name"};
const auto result = mkfifo(name, 0666);
if(result) return error(errno);
constexpr auto writers{5};
constexpr auto messages{4};
for(auto idx = 0; idx < writers; ++idx)
{
const auto pid = fork();
if(pid < 0) return error(errno);
if(pid == 0)
{
std::cout << "child " << getpid() << std::endl;
for(auto idx = 0; idx < messages; ++idx)
{
const auto wfd = open(name, O_WRONLY | O_NONBLOCK);
if(wfd < 0) return error(errno);
const auto msg{std::to_string(getpid())};
if(write(wfd, msg.data(), msg.size() + 1) < 0) error(errno);
close(wfd);
}
return 0;
}
}
{
std::cout << "parent" << std::endl;
const auto rfd = open(name, O_RDONLY);
const auto wfd = open(name, O_WRONLY);
if(rfd < 0) return error(errno);
for(auto idx = 0; idx < writers * messages; ++idx)
{
std::string buffer;
buffer.resize(80);
if(read(rfd, &buffer[0], buffer.size()) < 0) error(errno);
std::cout << buffer << std::endl;
}
close(wfd);
close(rfd);
}
if(unlink(name) < 0) return error(errno);
return 0;
}
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Sv: Sv: Sv: Named pipes and multiple writers
2020-03-27 14:53 ` Sv: " sten.kristian.ivarsson
@ 2020-03-27 22:56 ` Ken Brown
2020-03-27 23:00 ` Ken Brown
2020-03-28 12:10 ` Sv: " sten.kristian.ivarsson
0 siblings, 2 replies; 30+ messages in thread
From: Ken Brown @ 2020-03-27 22:56 UTC (permalink / raw)
To: sten.kristian.ivarsson; +Cc: 'cygwin'
On 3/27/2020 10:53 AM, sten.kristian.ivarsson@gmail.com wrote:
>> On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote:
>>> On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote:
>>>> On 3/26/2020 6:01 PM, sten.kristian.ivarsson@gmail.com wrote:
>>>>> The ENIXIO occurs when parallel child-processes simultaneously using
>>>>> O_NONBLOCK opening the descriptor.
>>>>
>>>> This is consistent with my guess that the error is generated by
>>>> fhandler_fifo::wait. I have a feeling that read_ready should have
>>>> been created as a manual-reset event, and that more care is needed to
>>>> make sure it's set when it should be.
>>>>
>>>>> I could provide a code-snippet
>>>>> to reproduce it if wanted ?
>>>>
>>>> Yes, please!
>>>
>>> That might not be necessary. If you're able to build the git repo
>>> master branch, please try the attached patch.
>
>> Here's a better patch.
>
>
> I finally succeeded to build latest master (make is not my favourite tool)
> and added the patch, but still no success in my little test-program (see
> attachment) when creating a write-file-descriptor with O_NONBLOCK
Your test program fails for me on Linux too. Here's the output from one run:
child 657
657 error: 6 No such device or address
child 658
child 659
658659 error: child 660
parent
child 661
error: 66606661 661 661
error: 661
No such device or address6No such device or address
No such device or address
[I then killed it with control-C; the parent was blocked trying to open the FIFO.]
There's a race condition in your code. The parent is trying to open the FIFO
for reading (without O_NONBLOCK) while the child is trying to open it for
writing (with O_NONBLOCK). The parent is blocked waiting for the child, and the
child's open fails with ENXIO; see
https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html#tag_16_357
I think you need to rearrange things so that the FIFO is open for reading before
you try a nonblocking open for writing.
I can work around the race by using a small positive 'wait' in
fhandler_fifo::wait(), but I'm not sure this is the right thing to do, since
Cygwin aims to emulate Linux. Can you find a test case that works on Linux but
fails on Cygwin?
Ken
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Sv: Sv: Sv: Named pipes and multiple writers
2020-03-27 22:56 ` Ken Brown
@ 2020-03-27 23:00 ` Ken Brown
2020-03-28 12:10 ` Sv: " sten.kristian.ivarsson
1 sibling, 0 replies; 30+ messages in thread
From: Ken Brown @ 2020-03-27 23:00 UTC (permalink / raw)
To: sten.kristian.ivarsson; +Cc: 'cygwin'
On 3/27/2020 6:56 PM, Ken Brown via Cygwin wrote:
> On 3/27/2020 10:53 AM, sten.kristian.ivarsson@gmail.com wrote:
>>> On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote:
>>>> On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote:
>>>>> On 3/26/2020 6:01 PM, sten.kristian.ivarsson@gmail.com wrote:
>>>>>> The ENIXIO occurs when parallel child-processes simultaneously using
>>>>>> O_NONBLOCK opening the descriptor.
>>>>>
>>>>> This is consistent with my guess that the error is generated by
>>>>> fhandler_fifo::wait. I have a feeling that read_ready should have
>>>>> been created as a manual-reset event, and that more care is needed to
>>>>> make sure it's set when it should be.
>>>>>
>>>>>> I could provide a code-snippet
>>>>>> to reproduce it if wanted ?
>>>>>
>>>>> Yes, please!
>>>>
>>>> That might not be necessary. If you're able to build the git repo
>>>> master branch, please try the attached patch.
>>
>>> Here's a better patch.
>>
>>
>> I finally succeeded to build latest master (make is not my favourite tool)
>> and added the patch, but still no success in my little test-program (see
>> attachment) when creating a write-file-descriptor with O_NONBLOCK
>
> Your test program fails for me on Linux too. Here's the output from one run:
>
> child 657
> 657 error: 6 No such device or address
> child 658
> child 659
> 658659 error: child 660
> parent
> child 661
> error: 66606661 661 661
> error: 661
> No such device or address6No such device or address
>
> No such device or address
>
> [I then killed it with control-C; the parent was blocked trying to open the FIFO.]
>
> There's a race condition in your code. The parent is trying to open the FIFO
> for reading (without O_NONBLOCK) while the child is trying to open it for
> writing (with O_NONBLOCK). The parent is blocked waiting for the child, and the
> child's open fails with ENXIO; see
>
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html#tag_16_357
>
> I think you need to rearrange things so that the FIFO is open for reading before
> you try a nonblocking open for writing.
For example, you could open it with O_RDWR instead of O_RDONLY.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Sv: Sv: Sv: Sv: Named pipes and multiple writers
2020-03-27 22:56 ` Ken Brown
2020-03-27 23:00 ` Ken Brown
@ 2020-03-28 12:10 ` sten.kristian.ivarsson
2020-03-28 15:43 ` Ken Brown
1 sibling, 1 reply; 30+ messages in thread
From: sten.kristian.ivarsson @ 2020-03-28 12:10 UTC (permalink / raw)
To: 'Ken Brown'; +Cc: 'cygwin'
>On 3/27/2020 10:53 AM, sten.kristian.ivarsson@gmail.com wrote:
>>> On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote:
>>>> On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote:
>>>>> On 3/26/2020 6:01 PM, sten.kristian.ivarsson@gmail.com wrote:
>>>>>> The ENIXIO occurs when parallel child-processes simultaneously
>>>>>> using O_NONBLOCK opening the descriptor.
>>>>>
>>>>> This is consistent with my guess that the error is generated by
>>>>> fhandler_fifo::wait. I have a feeling that read_ready should have
>>>>> been created as a manual-reset event, and that more care is needed
>>>>> to make sure it's set when it should be.
>>>>>
>>>>>> I could provide a code-snippet
>>>>>> to reproduce it if wanted ?
>>>>>
>>>>> Yes, please!
>>>>
>>>> That might not be necessary. If you're able to build the git repo
>>>> master branch, please try the attached patch.
>>
>>> Here's a better patch.
>>
>>
>> I finally succeeded to build latest master (make is not my favourite
>> tool) and added the patch, but still no success in my little
>> test-program (see
>> attachment) when creating a write-file-descriptor with O_NONBLOCK
>Your test program fails for me on Linux too. Here's the output from one
run:
You're right. That was extremely careless of me to not test this in Linux
first :-)
I can assure that we have a use case that works on Linux but not in Cygwin,
but it seems like I failed to narrow it down in the wrong way
I'll try to rearrange my code (that works in Linux) to mimic our application
but in a simple way (I'll be back)
[snip]
>Ken
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Sv: Sv: Sv: Sv: Named pipes and multiple writers
2020-03-28 12:10 ` Sv: " sten.kristian.ivarsson
@ 2020-03-28 15:43 ` Ken Brown
2020-03-29 2:19 ` Ken Brown
0 siblings, 1 reply; 30+ messages in thread
From: Ken Brown @ 2020-03-28 15:43 UTC (permalink / raw)
To: sten.kristian.ivarsson; +Cc: 'cygwin'
On 3/28/2020 8:10 AM, sten.kristian.ivarsson@gmail.com wrote:
>> On 3/27/2020 10:53 AM, sten.kristian.ivarsson@gmail.com wrote:
>>>> On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote:
>>>>> On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote:
>>>>>> On 3/26/2020 6:01 PM, sten.kristian.ivarsson@gmail.com wrote:
>>>>>>> The ENIXIO occurs when parallel child-processes simultaneously
>>>>>>> using O_NONBLOCK opening the descriptor.
>>>>>>
>>>>>> This is consistent with my guess that the error is generated by
>>>>>> fhandler_fifo::wait. I have a feeling that read_ready should have
>>>>>> been created as a manual-reset event, and that more care is needed
>>>>>> to make sure it's set when it should be.
>>>>>>
>>>>>>> I could provide a code-snippet
>>>>>>> to reproduce it if wanted ?
>>>>>>
>>>>>> Yes, please!
>>>>>
>>>>> That might not be necessary. If you're able to build the git repo
>>>>> master branch, please try the attached patch.
>>>
>>>> Here's a better patch.
>>>
>>>
>>> I finally succeeded to build latest master (make is not my favourite
>>> tool) and added the patch, but still no success in my little
>>> test-program (see
>>> attachment) when creating a write-file-descriptor with O_NONBLOCK
>
>> Your test program fails for me on Linux too. Here's the output from one
> run:
>
> You're right. That was extremely careless of me to not test this in Linux
> first :-)
No problem.
> I can assure that we have a use case that works on Linux but not in Cygwin,
> but it seems like I failed to narrow it down in the wrong way
>
> I'll try to rearrange my code (that works in Linux) to mimic our application
> but in a simple way (I'll be back)
OK, I'll be waiting for you. BTW, if it's not too hard to write your test case
in plain C, or at least less modern C++, that would simplify things for me. For
example, your pipe.cpp failed to compile on one Linux machine I wanted to test
it on, presumably because that machine had an older C++ compiler.
Ken
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Sv: Sv: Sv: Sv: Named pipes and multiple writers
2020-03-28 15:43 ` Ken Brown
@ 2020-03-29 2:19 ` Ken Brown
2020-03-30 17:44 ` Ken Brown
0 siblings, 1 reply; 30+ messages in thread
From: Ken Brown @ 2020-03-29 2:19 UTC (permalink / raw)
To: sten.kristian.ivarsson; +Cc: 'cygwin'
On 3/28/2020 11:43 AM, Ken Brown via Cygwin wrote:
> On 3/28/2020 8:10 AM, sten.kristian.ivarsson@gmail.com wrote:
>>> On 3/27/2020 10:53 AM, sten.kristian.ivarsson@gmail.com wrote:
>>>>> On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote:
>>>>>> On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote:
>>>>>>> On 3/26/2020 6:01 PM, sten.kristian.ivarsson@gmail.com wrote:
>>>>>>>> The ENIXIO occurs when parallel child-processes simultaneously
>>>>>>>> using O_NONBLOCK opening the descriptor.
>>>>>>>
>>>>>>> This is consistent with my guess that the error is generated by
>>>>>>> fhandler_fifo::wait. I have a feeling that read_ready should have
>>>>>>> been created as a manual-reset event, and that more care is needed
>>>>>>> to make sure it's set when it should be.
>>>>>>>
>>>>>>>> I could provide a code-snippet
>>>>>>>> to reproduce it if wanted ?
>>>>>>>
>>>>>>> Yes, please!
>>>>>>
>>>>>> That might not be necessary. If you're able to build the git repo
>>>>>> master branch, please try the attached patch.
>>>>
>>>>> Here's a better patch.
>>>>
>>>>
>>>> I finally succeeded to build latest master (make is not my favourite
>>>> tool) and added the patch, but still no success in my little
>>>> test-program (see
>>>> attachment) when creating a write-file-descriptor with O_NONBLOCK
>>
>>> Your test program fails for me on Linux too. Here's the output from one
>> run:
>>
>> You're right. That was extremely careless of me to not test this in Linux
>> first :-)
>
> No problem.
>
>> I can assure that we have a use case that works on Linux but not in Cygwin,
>> but it seems like I failed to narrow it down in the wrong way
>>
>> I'll try to rearrange my code (that works in Linux) to mimic our application
>> but in a simple way (I'll be back)
>
> OK, I'll be waiting for you. BTW, if it's not too hard to write your test case
> in plain C, or at least less modern C++, that would simplify things for me. For
> example, your pipe.cpp failed to compile on one Linux machine I wanted to test
> it on, presumably because that machine had an older C++ compiler.
Never mind. I was able to reproduce the problem and find the cause. What
happens is that when the first subprocess exits, fhandler_fifo::close resets
read_ready. That causes the second and subsequent subprocesses to think that
there's no reader open, so their attempts to open a writer with O_NONBLOCK fail
with ENXIO.
I should be able to fix this tomorrow.
Ken
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Sv: Sv: Sv: Sv: Named pipes and multiple writers
2020-03-29 2:19 ` Ken Brown
@ 2020-03-30 17:44 ` Ken Brown
2020-03-31 21:10 ` Sv: " sten.kristian.ivarsson
0 siblings, 1 reply; 30+ messages in thread
From: Ken Brown @ 2020-03-30 17:44 UTC (permalink / raw)
To: sten.kristian.ivarsson; +Cc: 'cygwin'
[-- Attachment #1: Type: text/plain, Size: 3675 bytes --]
On 3/28/2020 10:19 PM, Ken Brown via Cygwin wrote:
> On 3/28/2020 11:43 AM, Ken Brown via Cygwin wrote:
>> On 3/28/2020 8:10 AM, sten.kristian.ivarsson@gmail.com wrote:
>>>> On 3/27/2020 10:53 AM, sten.kristian.ivarsson@gmail.com wrote:
>>>>>> On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote:
>>>>>>> On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote:
>>>>>>>> On 3/26/2020 6:01 PM, sten.kristian.ivarsson@gmail.com wrote:
>>>>>>>>> The ENIXIO occurs when parallel child-processes simultaneously
>>>>>>>>> using O_NONBLOCK opening the descriptor.
>>>>>>>>
>>>>>>>> This is consistent with my guess that the error is generated by
>>>>>>>> fhandler_fifo::wait. I have a feeling that read_ready should have
>>>>>>>> been created as a manual-reset event, and that more care is needed
>>>>>>>> to make sure it's set when it should be.
>>>>>>>>
>>>>>>>>> I could provide a code-snippet
>>>>>>>>> to reproduce it if wanted ?
>>>>>>>>
>>>>>>>> Yes, please!
>>>>>>>
>>>>>>> That might not be necessary. If you're able to build the git repo
>>>>>>> master branch, please try the attached patch.
>>>>>
>>>>>> Here's a better patch.
>>>>>
>>>>>
>>>>> I finally succeeded to build latest master (make is not my favourite
>>>>> tool) and added the patch, but still no success in my little
>>>>> test-program (see
>>>>> attachment) when creating a write-file-descriptor with O_NONBLOCK
>>>
>>>> Your test program fails for me on Linux too. Here's the output from one
>>> run:
>>>
>>> You're right. That was extremely careless of me to not test this in Linux
>>> first :-)
>>
>> No problem.
>>
>>> I can assure that we have a use case that works on Linux but not in Cygwin,
>>> but it seems like I failed to narrow it down in the wrong way
>>>
>>> I'll try to rearrange my code (that works in Linux) to mimic our application
>>> but in a simple way (I'll be back)
>>
>> OK, I'll be waiting for you. BTW, if it's not too hard to write your test
>> case in plain C, or at least less modern C++, that would simplify things for
>> me. For example, your pipe.cpp failed to compile on one Linux machine I
>> wanted to test it on, presumably because that machine had an older C++ compiler.
>
> Never mind. I was able to reproduce the problem and find the cause. What
> happens is that when the first subprocess exits, fhandler_fifo::close resets
> read_ready. That causes the second and subsequent subprocesses to think that
> there's no reader open, so their attempts to open a writer with O_NONBLOCK fail
> with ENXIO.
>
> I should be able to fix this tomorrow.
I've pushed what I think is a fix to the topic/fifo branch. I tested it with
the attached program, which is a variant of the test case you sent last week.
Please test it in your use case.
Note: If you've previously pulled the topic/fifo branch, then you will probably
get a lot of conflicts when you pull again, because I did a forced push a few
days ago. If that happens, just do
git reset --hard origin/topic/fifo
It turned out that the fix required some of the ideas that I've been working on
in connection with allowing multiple readers. Even though the code allows a
FIFO to be *explicitly* opened for reading only once, there can still be several
open file descriptors for readers because of dup and fork. The existing code on
git master doesn't handle those situations properly.
The code on topic/fifo doesn't completely fix that yet, but I think it should
work under the following assumptions:
1. The FIFO is opened only once for reading.
2. The file descriptor obtained from this is the only one on which a read is
attempted.
I'm working on removing both of these restrictions.
Ken
[-- Attachment #2: fifo_fork_nonblocking_writers.c --]
[-- Type: text/plain, Size: 1639 bytes --]
/* Adapted from
https://sourceware.org/pipermail/cygwin/2020-March/244219.html */
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/wait.h>
#include <string.h>
#define FIFO "/tmp/myfifo"
#define nsubproc 5
#define nmessages 4
#define pid_len 4
int
error (const int n, const char *name)
{
fprintf (stderr, "\n%d\t%s:\t%d\t%s\n", getpid (), name, n, strerror (n));
return n;
}
int
main ()
{
if (mkfifo (FIFO, S_IRUSR | S_IWUSR | S_IWGRP) < 0
&& errno != EEXIST)
return error (errno, "mkfifo");
int rfd = open (FIFO, O_RDWR);
if (rfd < 0)
return error (errno, "open reader");
for (int i = 0; i < nsubproc; i++)
{
pid_t pid = fork ();
if (pid < 0)
return error (errno, "fork");
if (pid == 0)
{
printf ("child %d\n", getpid ());
for (int j = 0; j < nmessages; j++)
{
char buf[pid_len + 2]; /* +1 for newline, +1 for nul */
int wfd = open (FIFO, O_WRONLY | O_NONBLOCK);
if (wfd < 0)
_exit (error (errno, "open writer"));
sprintf (buf, "%d\n", getpid ());
ssize_t nwritten = write (wfd, buf, strlen (buf));
if (nwritten < 0)
error (errno, "write");
/* printf ("i = %d, j = %d, nwritten = %zd\n", i, j, nwritten); */
close (wfd);
}
_exit (0);
}
}
printf ("parent\n");
char buf[pid_len + 2];
for (int i = 0; i < nsubproc; i++)
for (int j = 0; j < nmessages; j++)
{
if (read (rfd, buf, nsubproc) < 0)
error (errno, "read");
buf[pid_len + 1] = '\0';
printf ("%s", buf);
}
close (rfd);
}
^ permalink raw reply [flat|nested] 30+ messages in thread
* Sv: Sv: Sv: Sv: Sv: Named pipes and multiple writers
2020-03-30 17:44 ` Ken Brown
@ 2020-03-31 21:10 ` sten.kristian.ivarsson
2020-03-31 22:02 ` Ken Brown
0 siblings, 1 reply; 30+ messages in thread
From: sten.kristian.ivarsson @ 2020-03-31 21:10 UTC (permalink / raw)
To: 'Ken Brown'; +Cc: 'cygwin'
[-- Attachment #1: Type: text/plain, Size: 4305 bytes --]
>On 3/28/2020 10:19 PM, Ken Brown via Cygwin wrote:
>> On 3/28/2020 11:43 AM, Ken Brown via Cygwin wrote:
>>> On 3/28/2020 8:10 AM, sten.kristian.ivarsson@gmail.com wrote:
>>>>> On 3/27/2020 10:53 AM, sten.kristian.ivarsson@gmail.com wrote:
>>>>>>> On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote:
>>>>>>>> On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote:
>>>>>>>>> On 3/26/2020 6:01 PM, sten.kristian.ivarsson@gmail.com wrote:
>>>>>>>>>> The ENIXIO occurs when parallel child-processes simultaneously
>>>>>>>>>> using O_NONBLOCK opening the descriptor.
>>>>>>>>>
>>>>>>>>> This is consistent with my guess that the error is generated by
>>>>>>>>> fhandler_fifo::wait. I have a feeling that read_ready should
>>>>>>>>> have been created as a manual-reset event, and that more care
>>>>>>>>> is needed to make sure it's set when it should be.
>>>>>>>>>
>>>>>>>>>> I could provide a code-snippet to reproduce it if wanted ?
>>>>>>>>>
>>>>>>>>> Yes, please!
>>>>>>>>
>>>>>>>> That might not be necessary. If you're able to build the git
>>>>>>>> repo master branch, please try the attached patch.
>>>>>>
>>>>>>> Here's a better patch.
>>>>>>
>>>>>>
>>>>>> I finally succeeded to build latest master (make is not my
>>>>>> favourite
>>>>>> tool) and added the patch, but still no success in my little
>>>>>> test-program (see
>>>>>> attachment) when creating a write-file-descriptor with O_NONBLOCK
>>>>
>>>>> Your test program fails for me on Linux too. Here's the output
>>>>> from one
>>>> run:
>>>>
>>>> You're right. That was extremely careless of me to not test this in
>>>> Linux first :-)
>>>
>>> No problem.
>>>
>>>> I can assure that we have a use case that works on Linux but not in
>>>> Cygwin, but it seems like I failed to narrow it down in the wrong
>>>> way
>>>>
>>>> I'll try to rearrange my code (that works in Linux) to mimic our
>>>> application but in a simple way (I'll be back)
>>>
>>> OK, I'll be waiting for you. BTW, if it's not too hard to write your
>>> test case in plain C, or at least less modern C++, that would
>>> simplify things for me. For example, your pipe.cpp failed to compile
>>> on one Linux machine I wanted to test it on, presumably because that
machine had an older C++ compiler.
>>
>> Never mind. I was able to reproduce the problem and find the cause.
>> What happens is that when the first subprocess exits,
>> fhandler_fifo::close resets read_ready. That causes the second and
>> subsequent subprocesses to think that there's no reader open, so their
>> attempts to open a writer with O_NONBLOCK fail with ENXIO.
>>
>> I should be able to fix this tomorrow.
>I've pushed what I think is a fix to the topic/fifo branch. I tested it
with the attached program, which is a variant of the test case you sent last
week.
>Please test it in your use case.
>Note: If you've previously pulled the topic/fifo branch, then you will
probably get a lot of conflicts when you pull again, because I did a forced
push a few days ago. If that happens, just do
> git reset --hard origin/topic/fifo
>It turned out that the fix required some of the ideas that I've been
working on in connection with allowing multiple readers. Even though the
code allows a FIFO to be *explicitly* opened for reading only once, there
can still be several open file descriptors for readers because of dup and
fork. The existing code on git master doesn't handle those situations
properly.
>The code on topic/fifo doesn't completely fix that yet, but I think it
should work under the following assumptions:
>1. The FIFO is opened only once for reading.
>2. The file descriptor obtained from this is the only one on which a read
is attempted.
>I'm working on removing both of these restrictions.
>Ken
We finally took the time to make some kind of a simplified "hack" that works
on Ubuntu and BSD/OSX but with latest on master newlib-cygwin gave "ENXIO"
now and then but with your previous patch attached, there was no ENXIO but
::read returns EAGIN (until exhausted) (with cygwin) almost every run
I will try your newest things tomorrow
See latest attatched test-program (starts to get bloated but this time more
C-compatible though:-)
Kristian
[-- Attachment #2: pipe.cpp --]
[-- Type: text/plain, Size: 2462 bytes --]
#include <string.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>
#include <stdio.h>
#include <errno.h>
int print_error(const int error)
{
printf("%s\n", strerror(error));
return error;
}
struct Message
{
int pid;
int index;
};
int main()
{
const char* name = "/tmp/my_pipe";
const int result = mkfifo(name, 0666);
if (result)
return print_error(errno);
const int writers{5};
const int messages{5};
printf("open parent pipe\n");
const int rfd = open(name, O_RDONLY | O_NONBLOCK);
const int wfd = open(name, O_WRONLY);
if (rfd < 0)
return print_error(errno);
const int block_alternation[] = {0, O_NONBLOCK};
int pids[writers];
for (auto idx = 0; idx < writers; ++idx)
{
const auto pid = fork();
if (pid < 0)
return print_error(errno);
if (pid == 0)
{
printf("child %d\n", getpid());
for (int index = 0; index < messages; ++index)
{
const int wfd = open(name, O_WRONLY | block_alternation[index % 2]);
if (wfd < 0)
return print_error(errno);
Message message{getpid(), index};
short attempts{10000};
while (write(wfd, &message, sizeof(message)) == -1 && errno == EAGAIN && attempts > 0)
--attempts;
if(attempts == 0)
printf("child %d write - pipe busy\n", getpid());
close(wfd);
}
return 0;
}
pids[idx] = pid;
}
{
printf("parent read\n");
for (int idx = 0; idx < writers * messages; ++idx)
{
short attempts{10000};
Message message{};
while (::read(rfd, &message, sizeof(message)) == -1 && errno == EAGAIN && attempts > 0)
--attempts;
if (attempts == 0)
printf("parent %d read - pipe empty\n", getpid());
else
printf("message %d %d\n", message.index, message.pid);
}
// wait for children.
for (int idx = 0; idx < writers; ++idx)
{
int status = 0;
waitpid(pids[idx], &status, 0);
if (WIFEXITED(status))
printf("child exited %d\n", pids[idx]);
}
close(wfd);
close(rfd);
}
if (unlink(name) < 0)
return print_error(errno);
return 0;
}
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Sv: Sv: Sv: Sv: Sv: Named pipes and multiple writers
2020-03-31 21:10 ` Sv: " sten.kristian.ivarsson
@ 2020-03-31 22:02 ` Ken Brown
2020-04-01 7:45 ` Sv: " sten.kristian.ivarsson
2020-04-01 8:52 ` sten.kristian.ivarsson
0 siblings, 2 replies; 30+ messages in thread
From: Ken Brown @ 2020-03-31 22:02 UTC (permalink / raw)
To: sten.kristian.ivarsson; +Cc: 'cygwin'
On 3/31/2020 5:10 PM, sten.kristian.ivarsson@gmail.com wrote:
>> On 3/28/2020 10:19 PM, Ken Brown via Cygwin wrote:
>>> On 3/28/2020 11:43 AM, Ken Brown via Cygwin wrote:
>>>> On 3/28/2020 8:10 AM, sten.kristian.ivarsson@gmail.com wrote:
>>>>>> On 3/27/2020 10:53 AM, sten.kristian.ivarsson@gmail.com wrote:
>>>>>>>> On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote:
>>>>>>>>> On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote:
>>>>>>>>>> On 3/26/2020 6:01 PM, sten.kristian.ivarsson@gmail.com wrote:
>>>>>>>>>>> The ENIXIO occurs when parallel child-processes simultaneously
>>>>>>>>>>> using O_NONBLOCK opening the descriptor.
>>>>>>>>>>
>>>>>>>>>> This is consistent with my guess that the error is generated by
>>>>>>>>>> fhandler_fifo::wait. I have a feeling that read_ready should
>>>>>>>>>> have been created as a manual-reset event, and that more care
>>>>>>>>>> is needed to make sure it's set when it should be.
>>>>>>>>>>
>>>>>>>>>>> I could provide a code-snippet to reproduce it if wanted ?
>>>>>>>>>>
>>>>>>>>>> Yes, please!
>>>>>>>>>
>>>>>>>>> That might not be necessary. If you're able to build the git
>>>>>>>>> repo master branch, please try the attached patch.
>>>>>>>
>>>>>>>> Here's a better patch.
>>>>>>>
>>>>>>>
>>>>>>> I finally succeeded to build latest master (make is not my
>>>>>>> favourite
>>>>>>> tool) and added the patch, but still no success in my little
>>>>>>> test-program (see
>>>>>>> attachment) when creating a write-file-descriptor with O_NONBLOCK
>>>>>
>>>>>> Your test program fails for me on Linux too. Here's the output
>>>>>> from one
>>>>> run:
>>>>>
>>>>> You're right. That was extremely careless of me to not test this in
>>>>> Linux first :-)
>>>>
>>>> No problem.
>>>>
>>>>> I can assure that we have a use case that works on Linux but not in
>>>>> Cygwin, but it seems like I failed to narrow it down in the wrong
>>>>> way
>>>>>
>>>>> I'll try to rearrange my code (that works in Linux) to mimic our
>>>>> application but in a simple way (I'll be back)
>>>>
>>>> OK, I'll be waiting for you. BTW, if it's not too hard to write your
>>>> test case in plain C, or at least less modern C++, that would
>>>> simplify things for me. For example, your pipe.cpp failed to compile
>>>> on one Linux machine I wanted to test it on, presumably because that
> machine had an older C++ compiler.
>>>
>>> Never mind. I was able to reproduce the problem and find the cause.
>>> What happens is that when the first subprocess exits,
>>> fhandler_fifo::close resets read_ready. That causes the second and
>>> subsequent subprocesses to think that there's no reader open, so their
>>> attempts to open a writer with O_NONBLOCK fail with ENXIO.
>>>
>>> I should be able to fix this tomorrow.
>
>> I've pushed what I think is a fix to the topic/fifo branch. I tested it
> with the attached program, which is a variant of the test case you sent last
> week.
>> Please test it in your use case.
>
>> Note: If you've previously pulled the topic/fifo branch, then you will
> probably get a lot of conflicts when you pull again, because I did a forced
> push a few days ago. If that happens, just do
>
>> git reset --hard origin/topic/fifo
>
>> It turned out that the fix required some of the ideas that I've been
> working on in connection with allowing multiple readers. Even though the
> code allows a FIFO to be *explicitly* opened for reading only once, there
> can still be several open file descriptors for readers because of dup and
> fork. The existing code on git master doesn't handle those situations
> properly.
>
>> The code on topic/fifo doesn't completely fix that yet, but I think it
> should work under the following assumptions:
>
>> 1. The FIFO is opened only once for reading.
>
>> 2. The file descriptor obtained from this is the only one on which a read
> is attempted.
>
>> I'm working on removing both of these restrictions.
>
>> Ken
>
> We finally took the time to make some kind of a simplified "hack" that works
> on Ubuntu and BSD/OSX but with latest on master newlib-cygwin gave "ENXIO"
> now and then but with your previous patch attached, there was no ENXIO but
> ::read returns EAGIN (until exhausted) (with cygwin) almost every run
>
> I will try your newest things tomorrow
>
> See latest attatched test-program (starts to get bloated but this time more
> C-compatible though:-)
Thanks. This runs fine with the current HEAD of topic/fifo.
Ken
^ permalink raw reply [flat|nested] 30+ messages in thread
* Sv: Sv: Sv: Sv: Sv: Sv: Named pipes and multiple writers
2020-03-31 22:02 ` Ken Brown
@ 2020-04-01 7:45 ` sten.kristian.ivarsson
2020-04-01 13:47 ` Ken Brown
2020-04-01 8:52 ` sten.kristian.ivarsson
1 sibling, 1 reply; 30+ messages in thread
From: sten.kristian.ivarsson @ 2020-04-01 7:45 UTC (permalink / raw)
To: 'Ken Brown'; +Cc: 'cygwin'
> On 3/31/2020 5:10 PM, sten.kristian.ivarsson@gmail.com wrote:
> >> On 3/28/2020 10:19 PM, Ken Brown via Cygwin wrote:
> >>> On 3/28/2020 11:43 AM, Ken Brown via Cygwin wrote:
> >>>> On 3/28/2020 8:10 AM, sten.kristian.ivarsson@gmail.com wrote:
> >>>>>> On 3/27/2020 10:53 AM, sten.kristian.ivarsson@gmail.com wrote:
> >>>>>>>> On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote:
> >>>>>>>>> On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote:
> >>>>>>>>>> On 3/26/2020 6:01 PM, sten.kristian.ivarsson@gmail.com wrote:
> >>>>>>>>>>> The ENIXIO occurs when parallel child-processes
> >>>>>>>>>>> simultaneously using O_NONBLOCK opening the descriptor.
[snip]
> Thanks. This runs fine with the current HEAD of topic/fifo.
We are very grateful for your efforts
The test-program works fine now with the latest commits in topic/fifo
There are some (possible other) issues that make our application doesn't
work as in Linux and we haven't had the time to dig into what the problems
are yet. A quick guess is that it is related to signals and possible related
to pselect, but we need to dig deeper into the logic to narrow down the
problems. Shall we "close" this issue even if we find out that there's still
problems with "named pipes" later on ?
The application server (the open source project) that we're trying to make
work in Windows can be found here https://bitbucket.org/casualcore/ (if
interested)
Once again, tnx Ken
Kristian
> Ken
^ permalink raw reply [flat|nested] 30+ messages in thread
* Sv: Sv: Sv: Sv: Sv: Sv: Named pipes and multiple writers
2020-03-31 22:02 ` Ken Brown
2020-04-01 7:45 ` Sv: " sten.kristian.ivarsson
@ 2020-04-01 8:52 ` sten.kristian.ivarsson
2020-04-01 16:15 ` Ken Brown
1 sibling, 1 reply; 30+ messages in thread
From: sten.kristian.ivarsson @ 2020-04-01 8:52 UTC (permalink / raw)
To: 'Ken Brown'; +Cc: 'cygwin'
> On 3/31/2020 5:10 PM, sten.kristian.ivarsson@gmail.com wrote:
> >> On 3/28/2020 10:19 PM, Ken Brown via Cygwin wrote:
> >>> On 3/28/2020 11:43 AM, Ken Brown via Cygwin wrote:
> >>>> On 3/28/2020 8:10 AM, sten.kristian.ivarsson@gmail.com wrote:
> >>>>>> On 3/27/2020 10:53 AM, sten.kristian.ivarsson@gmail.com wrote:
> >>>>>>>> On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote:
> >>>>>>>>> On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote:
> >>>>>>>>>> On 3/26/2020 6:01 PM, sten.kristian.ivarsson@gmail.com wrote:
> >>>>>>>>>>> The ENIXIO occurs when parallel child-processes
> >>>>>>>>>>> simultaneously using O_NONBLOCK opening the descriptor.
> >>>>>>>>>>
> >>>>>>>>>> This is consistent with my guess that the error is generated
> >>>>>>>>>> by fhandler_fifo::wait. I have a feeling that read_ready
> >>>>>>>>>> should have been created as a manual-reset event, and that
> >>>>>>>>>> more care is needed to make sure it's set when it should be.
> >>>>>>>>>>
> >>>>>>>>>>> I could provide a code-snippet to reproduce it if wanted ?
> >>>>>>>>>>
> >>>>>>>>>> Yes, please!
> >>>>>>>>>
> >>>>>>>>> That might not be necessary. If you're able to build the git
> >>>>>>>>> repo master branch, please try the attached patch.
> >>>>>>>
> >>>>>>>> Here's a better patch.
> >>>>>>>
> >>>>>>>
> >>>>>>> I finally succeeded to build latest master (make is not my
> >>>>>>> favourite
> >>>>>>> tool) and added the patch, but still no success in my little
> >>>>>>> test-program (see
> >>>>>>> attachment) when creating a write-file-descriptor with
> >>>>>>> O_NONBLOCK
> >>>>>
> >>>>>> Your test program fails for me on Linux too. Here's the output
> >>>>>> from one
> >>>>> run:
> >>>>>
> >>>>> You're right. That was extremely careless of me to not test this
> >>>>> in Linux first :-)
> >>>>
> >>>> No problem.
> >>>>
> >>>>> I can assure that we have a use case that works on Linux but not
> >>>>> in Cygwin, but it seems like I failed to narrow it down in the
> >>>>> wrong way
> >>>>>
> >>>>> I'll try to rearrange my code (that works in Linux) to mimic our
> >>>>> application but in a simple way (I'll be back)
> >>>>
> >>>> OK, I'll be waiting for you. BTW, if it's not too hard to write
> >>>> your test case in plain C, or at least less modern C++, that would
> >>>> simplify things for me. For example, your pipe.cpp failed to
> >>>> compile on one Linux machine I wanted to test it on, presumably
> >>>> because that
> > machine had an older C++ compiler.
> >>>
> >>> Never mind. I was able to reproduce the problem and find the cause.
> >>> What happens is that when the first subprocess exits,
> >>> fhandler_fifo::close resets read_ready. That causes the second and
> >>> subsequent subprocesses to think that there's no reader open, so
> >>> their attempts to open a writer with O_NONBLOCK fail with ENXIO.
> >>>
> >>> I should be able to fix this tomorrow.
> >
> >> I've pushed what I think is a fix to the topic/fifo branch. I tested
> >> it
> > with the attached program, which is a variant of the test case you
> > sent last week.
> >> Please test it in your use case.
> >
> >> Note: If you've previously pulled the topic/fifo branch, then you
> >> will
> > probably get a lot of conflicts when you pull again, because I did a
> > forced push a few days ago. If that happens, just do
> >
> >> git reset --hard origin/topic/fifo
> >
> >> It turned out that the fix required some of the ideas that I've been
> > working on in connection with allowing multiple readers. Even though
> > the code allows a FIFO to be *explicitly* opened for reading only
> > once, there can still be several open file descriptors for readers
> > because of dup and fork. The existing code on git master doesn't
> > handle those situations properly.
> >
> >> The code on topic/fifo doesn't completely fix that yet, but I think
> >> it
> > should work under the following assumptions:
> >
> >> 1. The FIFO is opened only once for reading.
> >
> >> 2. The file descriptor obtained from this is the only one on which a
> >> read
> > is attempted.
> >
> >> I'm working on removing both of these restrictions.
> >
> >> Ken
> >
> > We finally took the time to make some kind of a simplified "hack" that
> > works on Ubuntu and BSD/OSX but with latest on master newlib-cygwin gave
"ENXIO"
> > now and then but with your previous patch attached, there was no ENXIO
> > but ::read returns EAGIN (until exhausted) (with cygwin) almost every
> > run
> >
> > I will try your newest things tomorrow
> >
> > See latest attatched test-program (starts to get bloated but this time
> > more C-compatible though:-)
>
> Thanks. This runs fine with the current HEAD of topic/fifo.
I wrote in a previous mail in this topic that it seemed to work fine for me
as well, but when I bumped up the numbers of writers and/or the number of
messages (e.g. 25/25) it starts to fail again
The initial thought is that we're bumping into some kind of system resource
limit, but I haven't had the time to dig into details (yet) (I'm sorry for
that)
Kristian
> Ken
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Sv: Sv: Sv: Sv: Sv: Sv: Named pipes and multiple writers
2020-04-01 7:45 ` Sv: " sten.kristian.ivarsson
@ 2020-04-01 13:47 ` Ken Brown
0 siblings, 0 replies; 30+ messages in thread
From: Ken Brown @ 2020-04-01 13:47 UTC (permalink / raw)
To: sten.kristian.ivarsson; +Cc: 'cygwin'
On 4/1/2020 3:45 AM, sten.kristian.ivarsson@gmail.com wrote:
>> On 3/31/2020 5:10 PM, sten.kristian.ivarsson@gmail.com wrote:
>>>> On 3/28/2020 10:19 PM, Ken Brown via Cygwin wrote:
>>>>> On 3/28/2020 11:43 AM, Ken Brown via Cygwin wrote:
>>>>>> On 3/28/2020 8:10 AM, sten.kristian.ivarsson@gmail.com wrote:
>>>>>>>> On 3/27/2020 10:53 AM, sten.kristian.ivarsson@gmail.com wrote:
>>>>>>>>>> On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote:
>>>>>>>>>>> On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote:
>>>>>>>>>>>> On 3/26/2020 6:01 PM, sten.kristian.ivarsson@gmail.com wrote:
>>>>>>>>>>>>> The ENIXIO occurs when parallel child-processes
>>>>>>>>>>>>> simultaneously using O_NONBLOCK opening the descriptor.
>
> [snip]
>
>> Thanks. This runs fine with the current HEAD of topic/fifo.
>
> We are very grateful for your efforts
>
> The test-program works fine now with the latest commits in topic/fifo
>
> There are some (possible other) issues that make our application doesn't
> work as in Linux and we haven't had the time to dig into what the problems
> are yet. A quick guess is that it is related to signals and possible related
> to pselect, but we need to dig deeper into the logic to narrow down the
> problems. Shall we "close" this issue even if we find out that there's still
> problems with "named pipes" later on ?
You can write again any time that you discover further problems. The Cygwin
project doesn't have any mechanism for closing issues.
> The application server (the open source project) that we're trying to make
> work in Windows can be found here https://bitbucket.org/casualcore/ (if
> interested)
Thanks, I'll take a look at some point.
> Once again, tnx Ken
Thank you for reporting the problem. The code probably hasn't been exercised
very much up to now.
Ken
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Sv: Sv: Sv: Sv: Sv: Sv: Named pipes and multiple writers
2020-04-01 8:52 ` sten.kristian.ivarsson
@ 2020-04-01 16:15 ` Ken Brown
2020-04-01 17:14 ` Sv: " sten.kristian.ivarsson
0 siblings, 1 reply; 30+ messages in thread
From: Ken Brown @ 2020-04-01 16:15 UTC (permalink / raw)
To: sten.kristian.ivarsson; +Cc: 'cygwin'
On 4/1/2020 4:52 AM, sten.kristian.ivarsson@gmail.com wrote:
>> On 3/31/2020 5:10 PM, sten.kristian.ivarsson@gmail.com wrote:
>>>> On 3/28/2020 10:19 PM, Ken Brown via Cygwin wrote:
>>>>> On 3/28/2020 11:43 AM, Ken Brown via Cygwin wrote:
>>>>>> On 3/28/2020 8:10 AM, sten.kristian.ivarsson@gmail.com wrote:
>>>>>>>> On 3/27/2020 10:53 AM, sten.kristian.ivarsson@gmail.com wrote:
>>>>>>>>>> On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote:
>>>>>>>>>>> On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote:
>>>>>>>>>>>> On 3/26/2020 6:01 PM, sten.kristian.ivarsson@gmail.com wrote:
>>>>>>>>>>>>> The ENIXIO occurs when parallel child-processes
>>>>>>>>>>>>> simultaneously using O_NONBLOCK opening the descriptor.
>>>>>>>>>>>>
>>>>>>>>>>>> This is consistent with my guess that the error is generated
>>>>>>>>>>>> by fhandler_fifo::wait. I have a feeling that read_ready
>>>>>>>>>>>> should have been created as a manual-reset event, and that
>>>>>>>>>>>> more care is needed to make sure it's set when it should be.
>>>>>>>>>>>>
>>>>>>>>>>>>> I could provide a code-snippet to reproduce it if wanted ?
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, please!
>>>>>>>>>>>
>>>>>>>>>>> That might not be necessary. If you're able to build the git
>>>>>>>>>>> repo master branch, please try the attached patch.
>>>>>>>>>
>>>>>>>>>> Here's a better patch.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I finally succeeded to build latest master (make is not my
>>>>>>>>> favourite
>>>>>>>>> tool) and added the patch, but still no success in my little
>>>>>>>>> test-program (see
>>>>>>>>> attachment) when creating a write-file-descriptor with
>>>>>>>>> O_NONBLOCK
>>>>>>>
>>>>>>>> Your test program fails for me on Linux too. Here's the output
>>>>>>>> from one
>>>>>>> run:
>>>>>>>
>>>>>>> You're right. That was extremely careless of me to not test this
>>>>>>> in Linux first :-)
>>>>>>
>>>>>> No problem.
>>>>>>
>>>>>>> I can assure that we have a use case that works on Linux but not
>>>>>>> in Cygwin, but it seems like I failed to narrow it down in the
>>>>>>> wrong way
>>>>>>>
>>>>>>> I'll try to rearrange my code (that works in Linux) to mimic our
>>>>>>> application but in a simple way (I'll be back)
>>>>>>
>>>>>> OK, I'll be waiting for you. BTW, if it's not too hard to write
>>>>>> your test case in plain C, or at least less modern C++, that would
>>>>>> simplify things for me. For example, your pipe.cpp failed to
>>>>>> compile on one Linux machine I wanted to test it on, presumably
>>>>>> because that
>>> machine had an older C++ compiler.
>>>>>
>>>>> Never mind. I was able to reproduce the problem and find the cause.
>>>>> What happens is that when the first subprocess exits,
>>>>> fhandler_fifo::close resets read_ready. That causes the second and
>>>>> subsequent subprocesses to think that there's no reader open, so
>>>>> their attempts to open a writer with O_NONBLOCK fail with ENXIO.
>>>>>
>>>>> I should be able to fix this tomorrow.
>>>
>>>> I've pushed what I think is a fix to the topic/fifo branch. I tested
>>>> it
>>> with the attached program, which is a variant of the test case you
>>> sent last week.
>>>> Please test it in your use case.
>>>
>>>> Note: If you've previously pulled the topic/fifo branch, then you
>>>> will
>>> probably get a lot of conflicts when you pull again, because I did a
>>> forced push a few days ago. If that happens, just do
>>>
>>>> git reset --hard origin/topic/fifo
>>>
>>>> It turned out that the fix required some of the ideas that I've been
>>> working on in connection with allowing multiple readers. Even though
>>> the code allows a FIFO to be *explicitly* opened for reading only
>>> once, there can still be several open file descriptors for readers
>>> because of dup and fork. The existing code on git master doesn't
>>> handle those situations properly.
>>>
>>>> The code on topic/fifo doesn't completely fix that yet, but I think
>>>> it
>>> should work under the following assumptions:
>>>
>>>> 1. The FIFO is opened only once for reading.
>>>
>>>> 2. The file descriptor obtained from this is the only one on which a
>>>> read
>>> is attempted.
>>>
>>>> I'm working on removing both of these restrictions.
>>>
>>>> Ken
>>>
>>> We finally took the time to make some kind of a simplified "hack" that
>>> works on Ubuntu and BSD/OSX but with latest on master newlib-cygwin gave
> "ENXIO"
>>> now and then but with your previous patch attached, there was no ENXIO
>>> but ::read returns EAGIN (until exhausted) (with cygwin) almost every
>>> run
>>>
>>> I will try your newest things tomorrow
>>>
>>> See latest attatched test-program (starts to get bloated but this time
>>> more C-compatible though:-)
>>
>> Thanks. This runs fine with the current HEAD of topic/fifo.
>
> I wrote in a previous mail in this topic that it seemed to work fine for me
> as well, but when I bumped up the numbers of writers and/or the number of
> messages (e.g. 25/25) it starts to fail again
>
> The initial thought is that we're bumping into some kind of system resource
> limit, but I haven't had the time to dig into details (yet) (I'm sorry for
> that)
Yes, it is a resource issue. There is a limit on the number of writers that can
be open at one time, currently 64. I chose that number arbitrarily, with no
idea what might actually be needed in practice, and it can easily be changed.
In addition, a writer isn't recognized as closed until a reader tries to read
and gets an error. In your example with 25/25, the list of writers quickly gets
to 64 before the parent ever tries to read.
I'll see if I can find a better way to manage this.
Ken
^ permalink raw reply [flat|nested] 30+ messages in thread
* Sv: Sv: Sv: Sv: Sv: Sv: Sv: Named pipes and multiple writers
2020-04-01 16:15 ` Ken Brown
@ 2020-04-01 17:14 ` sten.kristian.ivarsson
2020-04-01 18:34 ` Ken Brown
0 siblings, 1 reply; 30+ messages in thread
From: sten.kristian.ivarsson @ 2020-04-01 17:14 UTC (permalink / raw)
To: 'Ken Brown'; +Cc: 'cygwin'
> On 4/1/2020 4:52 AM, sten.kristian.ivarsson@gmail.com wrote:
> >> On 3/31/2020 5:10 PM, sten.kristian.ivarsson@gmail.com wrote:
> >>>> On 3/28/2020 10:19 PM, Ken Brown via Cygwin wrote:
> >>>>> On 3/28/2020 11:43 AM, Ken Brown via Cygwin wrote:
> >>>>>> On 3/28/2020 8:10 AM, sten.kristian.ivarsson@gmail.com wrote:
> >>>>>>>> On 3/27/2020 10:53 AM, sten.kristian.ivarsson@gmail.com wrote:
> >>>>>>>>>> On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote:
> >>>>>>>>>>> On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote:
> >>>>>>>>>>>> On 3/26/2020 6:01 PM, sten.kristian.ivarsson@gmail.com wrote:
> >>>>>>>>>>>>> The ENIXIO occurs when parallel child-processes
> >>>>>>>>>>>>> simultaneously using O_NONBLOCK opening the descriptor.
> >>>>>>>>>>>>
> >>>>>>>>>>>> This is consistent with my guess that the error is
> >>>>>>>>>>>> generated by fhandler_fifo::wait. I have a feeling that
> >>>>>>>>>>>> read_ready should have been created as a manual-reset
> >>>>>>>>>>>> event, and that more care is needed to make sure it's set
when it should be.
[snip]
> >>>>> Never mind. I was able to reproduce the problem and find the cause.
> >>>>> What happens is that when the first subprocess exits,
> >>>>> fhandler_fifo::close resets read_ready. That causes the second
> >>>>> and subsequent subprocesses to think that there's no reader open,
> >>>>> so their attempts to open a writer with O_NONBLOCK fail with ENXIO.
[snip]
> > I wrote in a previous mail in this topic that it seemed to work fine
> > for me as well, but when I bumped up the numbers of writers and/or the
> > number of messages (e.g. 25/25) it starts to fail again
[snip]
> Yes, it is a resource issue. There is a limit on the number of writers
that can be open at one
> time, currently 64. I chose that number arbitrarily, with no idea what
might actually be
> needed in practice, and it can easily be changed.
Does it have to be a limit at all ? We would rather see that the application
decide how much resources it would like to use. In our particular case there
will be a process-manager with an incoming pipe that possible several
thousands of processes will write to
Just for fiddling around (to figure out if this is the limit that make other
things work a bit odd), where's this 64 limit defined now ?
> In addition, a writer isn't recognized as closed until a reader tries to
read and gets an error.
> In your example with 25/25, the list of writers quickly gets to 64 before
the parent ever tries
> to read.
That explains the behaviour, but should there be some error returned from
open/write (maybe it is but I'm missing it) ?
> I'll see if I can find a better way to manage this.
>
> Ken
Kristian
Kristian
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Sv: Sv: Sv: Sv: Sv: Sv: Sv: Named pipes and multiple writers
2020-04-01 17:14 ` Sv: " sten.kristian.ivarsson
@ 2020-04-01 18:34 ` Ken Brown
2020-04-02 2:19 ` Ken Brown
0 siblings, 1 reply; 30+ messages in thread
From: Ken Brown @ 2020-04-01 18:34 UTC (permalink / raw)
To: sten.kristian.ivarsson; +Cc: 'cygwin'
On 4/1/2020 1:14 PM, sten.kristian.ivarsson@gmail.com wrote:
>> On 4/1/2020 4:52 AM, sten.kristian.ivarsson@gmail.com wrote:
>>>> On 3/31/2020 5:10 PM, sten.kristian.ivarsson@gmail.com wrote:
>>>>>> On 3/28/2020 10:19 PM, Ken Brown via Cygwin wrote:
>>>>>>> On 3/28/2020 11:43 AM, Ken Brown via Cygwin wrote:
>>>>>>>> On 3/28/2020 8:10 AM, sten.kristian.ivarsson@gmail.com wrote:
>>>>>>>>>> On 3/27/2020 10:53 AM, sten.kristian.ivarsson@gmail.com wrote:
>>>>>>>>>>>> On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote:
>>>>>>>>>>>>> On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote:
>>>>>>>>>>>>>> On 3/26/2020 6:01 PM, sten.kristian.ivarsson@gmail.com wrote:
>>>>>>>>>>>>>>> The ENIXIO occurs when parallel child-processes
>>>>>>>>>>>>>>> simultaneously using O_NONBLOCK opening the descriptor.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is consistent with my guess that the error is
>>>>>>>>>>>>>> generated by fhandler_fifo::wait. I have a feeling that
>>>>>>>>>>>>>> read_ready should have been created as a manual-reset
>>>>>>>>>>>>>> event, and that more care is needed to make sure it's set
> when it should be.
>
> [snip]
>
>>>>>>> Never mind. I was able to reproduce the problem and find the cause.
>>>>>>> What happens is that when the first subprocess exits,
>>>>>>> fhandler_fifo::close resets read_ready. That causes the second
>>>>>>> and subsequent subprocesses to think that there's no reader open,
>>>>>>> so their attempts to open a writer with O_NONBLOCK fail with ENXIO.
>
> [snip]
>
>>> I wrote in a previous mail in this topic that it seemed to work fine
>>> for me as well, but when I bumped up the numbers of writers and/or the
>>> number of messages (e.g. 25/25) it starts to fail again
>
> [snip]
>
>> Yes, it is a resource issue. There is a limit on the number of writers
> that can be open at one
>> time, currently 64. I chose that number arbitrarily, with no idea what
> might actually be
>> needed in practice, and it can easily be changed.
>
> Does it have to be a limit at all ? We would rather see that the application
> decide how much resources it would like to use. In our particular case there
> will be a process-manager with an incoming pipe that possible several
> thousands of processes will write to
I agree.
> Just for fiddling around (to figure out if this is the limit that make other
> things work a bit odd), where's this 64 limit defined now ?
It's MAX_CLIENTS, defined in fhandler.h. But there seem to be other resource
issues also; simply increasing MAX_CLIENTS doesn't solve the problem. I think
there are also problems with the number of threads, for example. Each time your
program forks, the subprocess inherits the rfd file descriptor and its
"fifo_reader_thread" starts up. This is unnecessary for your application, so I
tried disabling it (in fhandler_fifo::fixup_after_fork), just as an experiment.
But then I ran into some deadlocks, suggesting that one of the locks I'm using
isn't robust enough. So I've got a lot of things to work on.
>> In addition, a writer isn't recognized as closed until a reader tries to
> read and gets an error.
>> In your example with 25/25, the list of writers quickly gets to 64 before
> the parent ever tries
>> to read.
>
> That explains the behaviour, but should there be some error returned from
> open/write (maybe it is but I'm missing it) ?
The error is discovered in add_client_handler, called from thread_func. I think
you'll only see it if you run the program under strace. I'll see if I can find
a way to report it. Currently, there's a retry loop in fhandler_fifo::open when
a writer tries to open, and I think I need to limit the number of retries and
then error out.
Ken
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Sv: Sv: Sv: Sv: Sv: Sv: Sv: Named pipes and multiple writers
2020-04-01 18:34 ` Ken Brown
@ 2020-04-02 2:19 ` Ken Brown
2020-04-02 8:05 ` Sv: " sten.kristian.ivarsson
0 siblings, 1 reply; 30+ messages in thread
From: Ken Brown @ 2020-04-02 2:19 UTC (permalink / raw)
To: sten.kristian.ivarsson; +Cc: 'cygwin'
On 4/1/2020 2:34 PM, Ken Brown via Cygwin wrote:
> On 4/1/2020 1:14 PM, sten.kristian.ivarsson@gmail.com wrote:
>>> On 4/1/2020 4:52 AM, sten.kristian.ivarsson@gmail.com wrote:
>>>>> On 3/31/2020 5:10 PM, sten.kristian.ivarsson@gmail.com wrote:
>>>>>>> On 3/28/2020 10:19 PM, Ken Brown via Cygwin wrote:
>>>>>>>> On 3/28/2020 11:43 AM, Ken Brown via Cygwin wrote:
>>>>>>>>> On 3/28/2020 8:10 AM, sten.kristian.ivarsson@gmail.com wrote:
>>>>>>>>>>> On 3/27/2020 10:53 AM, sten.kristian.ivarsson@gmail.com wrote:
>>>>>>>>>>>>> On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote:
>>>>>>>>>>>>>> On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote:
>>>>>>>>>>>>>>> On 3/26/2020 6:01 PM, sten.kristian.ivarsson@gmail.com wrote:
>>>>>>>>>>>>>>>> The ENIXIO occurs when parallel child-processes
>>>>>>>>>>>>>>>> simultaneously using O_NONBLOCK opening the descriptor.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is consistent with my guess that the error is
>>>>>>>>>>>>>>> generated by fhandler_fifo::wait. I have a feeling that
>>>>>>>>>>>>>>> read_ready should have been created as a manual-reset
>>>>>>>>>>>>>>> event, and that more care is needed to make sure it's set
>> when it should be.
>>
>> [snip]
>>
>>>>>>>> Never mind. I was able to reproduce the problem and find the cause.
>>>>>>>> What happens is that when the first subprocess exits,
>>>>>>>> fhandler_fifo::close resets read_ready. That causes the second
>>>>>>>> and subsequent subprocesses to think that there's no reader open,
>>>>>>>> so their attempts to open a writer with O_NONBLOCK fail with ENXIO.
>>
>> [snip]
>>
>>>> I wrote in a previous mail in this topic that it seemed to work fine
>>>> for me as well, but when I bumped up the numbers of writers and/or the
>>>> number of messages (e.g. 25/25) it starts to fail again
>>
>> [snip]
>>
>>> Yes, it is a resource issue. There is a limit on the number of writers
>> that can be open at one
>>> time, currently 64. I chose that number arbitrarily, with no idea what
>> might actually be
>>> needed in practice, and it can easily be changed.
>>
>> Does it have to be a limit at all ? We would rather see that the application
>> decide how much resources it would like to use. In our particular case there
>> will be a process-manager with an incoming pipe that possible several
>> thousands of processes will write to
>
> I agree.
>
>> Just for fiddling around (to figure out if this is the limit that make other
>> things work a bit odd), where's this 64 limit defined now ?
>
> It's MAX_CLIENTS, defined in fhandler.h. But there seem to be other resource
> issues also; simply increasing MAX_CLIENTS doesn't solve the problem. I think
> there are also problems with the number of threads, for example. Each time your
> program forks, the subprocess inherits the rfd file descriptor and its
> "fifo_reader_thread" starts up. This is unnecessary for your application, so I
> tried disabling it (in fhandler_fifo::fixup_after_fork), just as an experiment.
>
> But then I ran into some deadlocks, suggesting that one of the locks I'm using
> isn't robust enough. So I've got a lot of things to work on.
>
>>> In addition, a writer isn't recognized as closed until a reader tries to
>> read and gets an error.
>>> In your example with 25/25, the list of writers quickly gets to 64 before
>> the parent ever tries
>>> to read.
>>
>> That explains the behaviour, but should there be some error returned from
>> open/write (maybe it is but I'm missing it) ?
>
> The error is discovered in add_client_handler, called from thread_func. I think
> you'll only see it if you run the program under strace. I'll see if I can find
> a way to report it. Currently, there's a retry loop in fhandler_fifo::open when
> a writer tries to open, and I think I need to limit the number of retries and
> then error out.
I pushed a few improvements and bug fixes, and your 25/25 example now runs
without a problem. I increased MAX_CLIENTS to 1024 just for the sake of this
example, but I'll work on letting the number of writers increase dynamically as
needed.
Ken
^ permalink raw reply [flat|nested] 30+ messages in thread
* Sv: Sv: Sv: Sv: Sv: Sv: Sv: Sv: Named pipes and multiple writers
2020-04-02 2:19 ` Ken Brown
@ 2020-04-02 8:05 ` sten.kristian.ivarsson
2020-04-02 12:47 ` Sv: Sv: Sv: Sv: Sv: Sv: Sv: Sv: Named pipes and multiple wri Gregery Barton
2020-04-02 18:21 ` Sv: Sv: Sv: Sv: Sv: Sv: Sv: Sv: Named pipes and multiple writers Ken Brown
0 siblings, 2 replies; 30+ messages in thread
From: sten.kristian.ivarsson @ 2020-04-02 8:05 UTC (permalink / raw)
To: 'Ken Brown'; +Cc: 'cygwin'
> On 4/1/2020 2:34 PM, Ken Brown via Cygwin wrote:
> > On 4/1/2020 1:14 PM, sten.kristian.ivarsson@gmail.com wrote:
> >>> On 4/1/2020 4:52 AM, sten.kristian.ivarsson@gmail.com wrote:
> >>>>> On 3/31/2020 5:10 PM, sten.kristian.ivarsson@gmail.com wrote:
> >>>>>>> On 3/28/2020 10:19 PM, Ken Brown via Cygwin wrote:
> >>>>>>>> On 3/28/2020 11:43 AM, Ken Brown via Cygwin wrote:
> >>>>>>>>> On 3/28/2020 8:10 AM, sten.kristian.ivarsson@gmail.com wrote:
> >>>>>>>>>>> On 3/27/2020 10:53 AM, sten.kristian.ivarsson@gmail.com wrote:
> >>>>>>>>>>>>> On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote:
> >>>>>>>>>>>>>> On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote:
> >>>>>>>>>>>>>>> On 3/26/2020 6:01 PM, sten.kristian.ivarsson@gmail.com
wrote:
> >>>>>>>>>>>>>>>> The ENIXIO occurs when parallel child-processes
> >>>>>>>>>>>>>>>> simultaneously using O_NONBLOCK opening the descriptor.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> This is consistent with my guess that the error is
> >>>>>>>>>>>>>>> generated by fhandler_fifo::wait. I have a feeling that
> >>>>>>>>>>>>>>> read_ready should have been created as a manual-reset
> >>>>>>>>>>>>>>> event, and that more care is needed to make sure it's
> >>>>>>>>>>>>>>> set
> >> when it should be.
> >>
> >> [snip]
> >>
> >>>>>>>> Never mind. I was able to reproduce the problem and find the
cause.
> >>>>>>>> What happens is that when the first subprocess exits,
> >>>>>>>> fhandler_fifo::close resets read_ready. That causes the second
> >>>>>>>> and subsequent subprocesses to think that there's no reader
> >>>>>>>> open, so their attempts to open a writer with O_NONBLOCK fail
with ENXIO.
> >>
> >> [snip]
> >>
> >>>> I wrote in a previous mail in this topic that it seemed to work
> >>>> fine for me as well, but when I bumped up the numbers of writers
> >>>> and/or the number of messages (e.g. 25/25) it starts to fail again
> >>
> >> [snip]
> >>
> >>> Yes, it is a resource issue. There is a limit on the number of
> >>> writers
> >> that can be open at one
> >>> time, currently 64. I chose that number arbitrarily, with no idea
> >>> what
> >> might actually be
> >>> needed in practice, and it can easily be changed.
> >>
> >> Does it have to be a limit at all ? We would rather see that the
> >> application decide how much resources it would like to use. In our
> >> particular case there will be a process-manager with an incoming pipe
> >> that possible several thousands of processes will write to
> >
> > I agree.
> >
> >> Just for fiddling around (to figure out if this is the limit that
> >> make other things work a bit odd), where's this 64 limit defined now ?
> >
> > It's MAX_CLIENTS, defined in fhandler.h. But there seem to be other
> > resource issues also; simply increasing MAX_CLIENTS doesn't solve the
> > problem. I think there are also problems with the number of threads,
> > for example. Each time your program forks, the subprocess inherits
> > the rfd file descriptor and its "fifo_reader_thread" starts up. This
> > is unnecessary for your application, so I tried disabling it (in
> fhandler_fifo::fixup_after_fork), just as an experiment.
> >
> > But then I ran into some deadlocks, suggesting that one of the locks
> > I'm using isn't robust enough. So I've got a lot of things to work on.
> >
> >>> In addition, a writer isn't recognized as closed until a reader
> >>> tries to
> >> read and gets an error.
> >>> In your example with 25/25, the list of writers quickly gets to 64
> >>> before
> >> the parent ever tries
> >>> to read.
> >>
> >> That explains the behaviour, but should there be some error returned
> >> from open/write (maybe it is but I'm missing it) ?
> >
> > The error is discovered in add_client_handler, called from
> > thread_func. I think you'll only see it if you run the program under
> > strace. I'll see if I can find a way to report it. Currently,
> > there's a retry loop in fhandler_fifo::open when a writer tries to
> > open, and I think I need to limit the number of retries and then error
out.
>
> I pushed a few improvements and bug fixes, and your 25/25 example now runs
without a
> problem. I increased MAX_CLIENTS to 1024 just for the sake of this
example, but I'll
> work on letting the number of writers increase dynamically as needed.
I pulled it and tried it out and yes, the sample test program with 25/25
worked well and a whole bunch of our unit-tests passed with ok result now
We still do have some issues, but I cannot yet tell if they are related to
named pipes or not
It is great that you're looking into a totally dynamic solution
Kristian
> Ken
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Sv: Sv: Sv: Sv: Sv: Sv: Sv: Sv: Named pipes and multiple wri
2020-04-02 8:05 ` Sv: " sten.kristian.ivarsson
@ 2020-04-02 12:47 ` Gregery Barton
2020-04-02 18:21 ` Sv: Sv: Sv: Sv: Sv: Sv: Sv: Sv: Named pipes and multiple writers Ken Brown
1 sibling, 0 replies; 30+ messages in thread
From: Gregery Barton @ 2020-04-02 12:47 UTC (permalink / raw)
To: sten.kristian.ivarsson, Kristian Ivarsson via Cygwin,
'Ken Brown'
Cc: 'cygwin'
How do I unsubscribed from cygwin mailing lists? I tried simple unsubscribe but it's not so simple. I don't have a password and it won't send me one.
Sent from Yahoo7 Mail on Android
On Thu, 2 Apr 2020 at 7:06 pm, Kristian Ivarsson via Cygwin<cygwin@cygwin.com> wrote: > On 4/1/2020 2:34 PM, Ken Brown via Cygwin wrote:
> > On 4/1/2020 1:14 PM, sten.kristian.ivarsson@gmail.com wrote:
> >>> On 4/1/2020 4:52 AM, sten.kristian.ivarsson@gmail.com wrote:
> >>>>> On 3/31/2020 5:10 PM, sten.kristian.ivarsson@gmail.com wrote:
> >>>>>>> On 3/28/2020 10:19 PM, Ken Brown via Cygwin wrote:
> >>>>>>>> On 3/28/2020 11:43 AM, Ken Brown via Cygwin wrote:
> >>>>>>>>> On 3/28/2020 8:10 AM, sten.kristian.ivarsson@gmail.com wrote:
> >>>>>>>>>>> On 3/27/2020 10:53 AM, sten.kristian.ivarsson@gmail.com wrote:
> >>>>>>>>>>>>> On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote:
> >>>>>>>>>>>>>> On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote:
> >>>>>>>>>>>>>>> On 3/26/2020 6:01 PM, sten.kristian.ivarsson@gmail.com
wrote:
> >>>>>>>>>>>>>>>> The ENIXIO occurs when parallel child-processes
> >>>>>>>>>>>>>>>> simultaneously using O_NONBLOCK opening the descriptor.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> This is consistent with my guess that the error is
> >>>>>>>>>>>>>>> generated by fhandler_fifo::wait. I have a feeling that
> >>>>>>>>>>>>>>> read_ready should have been created as a manual-reset
> >>>>>>>>>>>>>>> event, and that more care is needed to make sure it's
> >>>>>>>>>>>>>>> set
> >> when it should be.
> >>
> >> [snip]
> >>
> >>>>>>>> Never mind. I was able to reproduce the problem and find the
cause.
> >>>>>>>> What happens is that when the first subprocess exits,
> >>>>>>>> fhandler_fifo::close resets read_ready. That causes the second
> >>>>>>>> and subsequent subprocesses to think that there's no reader
> >>>>>>>> open, so their attempts to open a writer with O_NONBLOCK fail
with ENXIO.
> >>
> >> [snip]
> >>
> >>>> I wrote in a previous mail in this topic that it seemed to work
> >>>> fine for me as well, but when I bumped up the numbers of writers
> >>>> and/or the number of messages (e.g. 25/25) it starts to fail again
> >>
> >> [snip]
> >>
> >>> Yes, it is a resource issue. There is a limit on the number of
> >>> writers
> >> that can be open at one
> >>> time, currently 64. I chose that number arbitrarily, with no idea
> >>> what
> >> might actually be
> >>> needed in practice, and it can easily be changed.
> >>
> >> Does it have to be a limit at all ? We would rather see that the
> >> application decide how much resources it would like to use. In our
> >> particular case there will be a process-manager with an incoming pipe
> >> that possible several thousands of processes will write to
> >
> > I agree.
> >
> >> Just for fiddling around (to figure out if this is the limit that
> >> make other things work a bit odd), where's this 64 limit defined now ?
> >
> > It's MAX_CLIENTS, defined in fhandler.h. But there seem to be other
> > resource issues also; simply increasing MAX_CLIENTS doesn't solve the
> > problem. I think there are also problems with the number of threads,
> > for example. Each time your program forks, the subprocess inherits
> > the rfd file descriptor and its "fifo_reader_thread" starts up. This
> > is unnecessary for your application, so I tried disabling it (in
> fhandler_fifo::fixup_after_fork), just as an experiment.
> >
> > But then I ran into some deadlocks, suggesting that one of the locks
> > I'm using isn't robust enough. So I've got a lot of things to work on.
> >
> >>> In addition, a writer isn't recognized as closed until a reader
> >>> tries to
> >> read and gets an error.
> >>> In your example with 25/25, the list of writers quickly gets to 64
> >>> before
> >> the parent ever tries
> >>> to read.
> >>
> >> That explains the behaviour, but should there be some error returned
> >> from open/write (maybe it is but I'm missing it) ?
> >
> > The error is discovered in add_client_handler, called from
> > thread_func. I think you'll only see it if you run the program under
> > strace. I'll see if I can find a way to report it. Currently,
> > there's a retry loop in fhandler_fifo::open when a writer tries to
> > open, and I think I need to limit the number of retries and then error
out.
>
> I pushed a few improvements and bug fixes, and your 25/25 example now runs
without a
> problem. I increased MAX_CLIENTS to 1024 just for the sake of this
example, but I'll
> work on letting the number of writers increase dynamically as needed.
I pulled it and tried it out and yes, the sample test program with 25/25
worked well and a whole bunch of our unit-tests passed with ok result now
We still do have some issues, but I cannot yet tell if they are related to
named pipes or not
It is great that you're looking into a totally dynamic solution
Kristian
> Ken
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Sv: Sv: Sv: Sv: Sv: Sv: Sv: Sv: Named pipes and multiple writers
2020-04-02 8:05 ` Sv: " sten.kristian.ivarsson
2020-04-02 12:47 ` Sv: Sv: Sv: Sv: Sv: Sv: Sv: Sv: Named pipes and multiple wri Gregery Barton
@ 2020-04-02 18:21 ` Ken Brown
1 sibling, 0 replies; 30+ messages in thread
From: Ken Brown @ 2020-04-02 18:21 UTC (permalink / raw)
To: sten.kristian.ivarsson; +Cc: 'cygwin'
On 4/2/2020 4:05 AM, sten.kristian.ivarsson@gmail.com wrote:
> It is great that you're looking into a totally dynamic solution
I've just pushed a first attempt at this. I tested it by running your test
program with parameters 50/50. It looks like there are about 2000 writers open
at once during this run.
Ken
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2020-04-02 18:21 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-25 11:11 Named pipes and multiple writers sten.kristian.ivarsson
2020-03-25 12:44 ` Ken Brown
[not found] ` <18be01d602ab$0bbfca30$233f5e90$@gmail.com>
2020-03-26 14:06 ` Sv: " Ken Brown
2020-03-26 15:11 ` Ken Brown
2020-03-26 16:03 ` Norton Allen
2020-03-26 16:44 ` Ken Brown
2020-03-26 17:00 ` Norton Allen
2020-03-26 22:01 ` Sv: " sten.kristian.ivarsson
2020-03-26 22:39 ` Ken Brown
2020-03-26 23:19 ` Ken Brown
2020-03-27 13:10 ` Ken Brown
2020-03-27 14:53 ` Sv: " sten.kristian.ivarsson
2020-03-27 22:56 ` Ken Brown
2020-03-27 23:00 ` Ken Brown
2020-03-28 12:10 ` Sv: " sten.kristian.ivarsson
2020-03-28 15:43 ` Ken Brown
2020-03-29 2:19 ` Ken Brown
2020-03-30 17:44 ` Ken Brown
2020-03-31 21:10 ` Sv: " sten.kristian.ivarsson
2020-03-31 22:02 ` Ken Brown
2020-04-01 7:45 ` Sv: " sten.kristian.ivarsson
2020-04-01 13:47 ` Ken Brown
2020-04-01 8:52 ` sten.kristian.ivarsson
2020-04-01 16:15 ` Ken Brown
2020-04-01 17:14 ` Sv: " sten.kristian.ivarsson
2020-04-01 18:34 ` Ken Brown
2020-04-02 2:19 ` Ken Brown
2020-04-02 8:05 ` Sv: " sten.kristian.ivarsson
2020-04-02 12:47 ` Sv: Sv: Sv: Sv: Sv: Sv: Sv: Sv: Named pipes and multiple wri Gregery Barton
2020-04-02 18:21 ` Sv: Sv: Sv: Sv: Sv: Sv: Sv: Sv: Named pipes and multiple writers Ken Brown
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).