Named pipes and multiple writers

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Named pipes and multiple writers

Cygwin list mailing list
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

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Named pipes and multiple writers

Cygwin list mailing list
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
--
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
Reply | Threaded
Open this post in threaded view
|

Re: Sv: Named pipes and multiple writers

Cygwin list mailing list
[Let's keep the discussion on the list in case others have suggestions.]

On 3/25/2020 9:41 AM, [hidden email] 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
--
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
Reply | Threaded
Open this post in threaded view
|

Re: Sv: Named pipes and multiple writers

Cygwin list mailing list
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, [hidden email] 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
--
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
Reply | Threaded
Open this post in threaded view
|

Re: Sv: Named pipes and multiple writers

Norton Allen
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
=============================================================

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Sv: Named pipes and multiple writers

Cygwin list mailing list
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
--
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
Reply | Threaded
Open this post in threaded view
|

Re: Sv: Named pipes and multiple writers

Norton Allen
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.


--
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
Reply | Threaded
Open this post in threaded view
|

Sv: Sv: Named pipes and multiple writers

Cygwin list mailing list
In reply to this post by Cygwin list mailing list
>> [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

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Sv: Sv: Named pipes and multiple writers

Cygwin list mailing list
On 3/26/2020 6:01 PM, [hidden email] 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
--
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
Reply | Threaded
Open this post in threaded view
|

Re: Sv: Sv: Named pipes and multiple writers

Cygwin list mailing list
On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote:

> On 3/26/2020 6:01 PM, [hidden email] 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

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

0001-Cygwin-FIFO-make-read_ready-a-manual-reset-event.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Sv: Sv: Named pipes and multiple writers

Cygwin list mailing list
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, [hidden email] 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

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

0001-Cygwin-FIFO-fix-a-problem-opening-nonblocking-writer.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Sv: Sv: Sv: Named pipes and multiple writers

Cygwin list mailing list
>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, [hidden email] 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

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

pipe.cpp (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Sv: Sv: Sv: Named pipes and multiple writers

Cygwin list mailing list
On 3/27/2020 10:53 AM, [hidden email] 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, [hidden email] 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
--
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
Reply | Threaded
Open this post in threaded view
|

Re: Sv: Sv: Sv: Named pipes and multiple writers

Cygwin list mailing list
On 3/27/2020 6:56 PM, Ken Brown via Cygwin wrote:

> On 3/27/2020 10:53 AM, [hidden email] 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, [hidden email] 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.
--
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
Reply | Threaded
Open this post in threaded view
|

Sv: Sv: Sv: Sv: Named pipes and multiple writers

Cygwin list mailing list
In reply to this post by Cygwin list mailing list
>On 3/27/2020 10:53 AM, [hidden email] 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, [hidden email] 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

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Sv: Sv: Sv: Sv: Named pipes and multiple writers

Cygwin list mailing list
On 3/28/2020 8:10 AM, [hidden email] wrote:

>> On 3/27/2020 10:53 AM, [hidden email] 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, [hidden email] 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
--
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
Reply | Threaded
Open this post in threaded view
|

Re: Sv: Sv: Sv: Sv: Named pipes and multiple writers

Cygwin list mailing list
On 3/28/2020 11:43 AM, Ken Brown via Cygwin wrote:

> On 3/28/2020 8:10 AM, [hidden email] wrote:
>>> On 3/27/2020 10:53 AM, [hidden email] 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, [hidden email] 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
--
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
Reply | Threaded
Open this post in threaded view
|

Re: Sv: Sv: Sv: Sv: Named pipes and multiple writers

Cygwin list mailing list
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, [hidden email] wrote:
>>>> On 3/27/2020 10:53 AM, [hidden email] 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, [hidden email] 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

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

fifo_fork_nonblocking_writers.c (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Sv: Sv: Sv: Sv: Sv: Named pipes and multiple writers

Cygwin list mailing list
>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, [hidden email] wrote:
>>>>> On 3/27/2020 10:53 AM, [hidden email] 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, [hidden email] 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


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

pipe.cpp (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Sv: Sv: Sv: Sv: Sv: Named pipes and multiple writers

Cygwin list mailing list
On 3/31/2020 5:10 PM, [hidden email] 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, [hidden email] wrote:
>>>>>> On 3/27/2020 10:53 AM, [hidden email] 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, [hidden email] 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
--
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
12