On 4/8/2020 4:52 AM, sten.kristian.ivars...@gmail.com wrote:
On 4/7/2020 2:38 PM, sten.kristian.ivars...@gmail.com wrote:
On 4/7/2020 11:10 AM, Kristian Ivarsson via Cygwin wrote:
Opening a (second) descriptor for (blocking) write sometimes fail

The provided test case sometimes succeed, but quite often fail with
ENOENT (in various indexes)

I haven't dug deeper to find the underlaying cause yet

Have anyone experienced this before ?

I can't reproduce this on my system.  I changed 1000 to 10000 and
then ran your test case 10 times, and it never failed.  I tested both
cygwin-3.1.4 and the HEAD of the topic/fifo branch (which I recently
force-pushed in case you want to try it).

Can you run your test under strace and see if that provides a clue?

I'm running things on a few year old laptop, perhaps with less muscles
;-)

With strace it was harder to reproduce, but I could reproduce it (and
it happen to be the first iteration this time)

Does this help?

--- a/winsup/cygwin/fhandler_fifo.cc
+++ b/winsup/cygwin/fhandler_fifo.cc
@@ -624,7 +624,8 @@ fhandler_fifo::open (int flags, mode_t)
                    else
                      goto success;
                  }
-             else if (STATUS_PIPE_NO_INSTANCE_AVAILABLE (status))
+             else if (STATUS_PIPE_NO_INSTANCE_AVAILABLE (status)
+                      | status == STATUS_OBJECT_NAME_NOT_FOUND)
                  continue;
                else
                  {

Did you mean to use the bit-or-operator or the or-operator ?

The or-operator.  Thanks for catching that.

I did
...
    else if (STATUS_PIPE_NO_INSTANCE_AVAILABLE (status) || status ==
STATUS_OBJECT_NAME_NOT_FOUND)
...
and with that change I cannot reproduce the error in the test-program

Great. I'll push it to the topic/fifo branch. For the record, that patch was motivated by your strace output, which showed NtOpenFile failing with status 0xC0000034, which is STATUS_OBJECT_NAME_NOT_FOUND.

We (with the open-source-application) do bump into some other issues later
in the chanin, but I haven't investigated what the issues are yet (lack of
time)
>

I'm a little confused why this "issue"/"report" didn't end up in the
cygwin-mailing list and why it became us having a private conversation ?

That was unintentional.  I've added the list back to the Cc.

We're grateful that you're taking your time to look into this. Do you have
any clue of what the chances are to get these fixes (topic/fifo) into the
master branch and finally into an official release (or at least a snap-shot)
?

It shouldn't be too much longer. I'll regret making this prediction, but I'd guess that the branch will be ready for wider testing within a few weeks.

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 via email to