From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) by sourceware.org (Postfix) with ESMTPS id 4567C385BF83 for ; Wed, 1 Apr 2020 08:52:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4567C385BF83 Received: by mail-lj1-x230.google.com with SMTP id 19so24857868ljj.7 for ; Wed, 01 Apr 2020 01:52:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=A14kA4twa6IuKP5O34dz3xbSDfRwuwaAcKeBCmbD+iU=; b=sLcy5ChyNCSf1NZtlZcuybhmT3FcrQNtiwlYkSxM8+OpJ3eLd7mSO9i4t39/sxGzKt 9SV9k10/j7znas6kxjOUBCy1giNHrggDPKJ0YY9IJOidoB2xwMsNCg4+w/Yr1djNzwYF RTti4gJjI1/kYkTdK1r0/Yekq6CvlYO8jqG4Dz8lxXdm7tLoNTzvBb1IUUTyasDyD+wb wpFhyjkr51hgSy8dNu5yJmjWsVglBn5ikOXi65dTwsG0Tf51jGd55hNPc//ywt26NTSE B5oYf4j82IWzNzVCADZWX6pvnf8im7zpc3uQHNyu7q+86D0Odu+2PAKW3oF9eKWMfdx3 zIzQ== X-Gm-Message-State: AGi0PuZjwpzlUHWDyXqOOUV4DdQBsgw7+i1XankdyAFoniGbNoHQgySb 6PNKD6M/vGrmnBa4OTqw6MEOqgIu X-Google-Smtp-Source: APiQypLYK/6KxTwjqWXJLPlV4HrOuGk34qbAEXcgI92DwQ1NjhnMrKhbCRq1xIGsohLWSZjHrhqxxA== X-Received: by 2002:a2e:87cc:: with SMTP id v12mr12509606ljj.127.1585731125446; Wed, 01 Apr 2020 01:52:05 -0700 (PDT) Received: from JOKK (87-249-164-127.ljusnet.se. [87.249.164.127]) by smtp.gmail.com with ESMTPSA id e4sm1085990lfn.80.2020.04.01.01.52.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2020 01:52:04 -0700 (PDT) From: To: "'Ken Brown'" Cc: "'cygwin'" References: <1b1401d60296$2769e690$763db3b0$@gmail.com> <716e2076-f607-454e-2723-937c3959e2a3@cornell.edu> <18be01d602ab$0bbfca30$233f5e90$@gmail.com> <35b43b59-6410-f21f-710c-385e39cbae0b@cornell.edu> <005201d603ba$2bc8ab20$835a0160$@gmail.com> <472d1df6-531a-ebd7-4ffa-583a06e270ff@cornell.edu> <00b901d60447$7ecb4c50$7c61e4f0$@gmail.com> <00e001d604f9$d0aa0720$71fe1560$@gmail.com> <8c6c5655-c162-8361-9f44-376bbd7cf114@cornell.edu> <3fe06192-7300-382a-8c98-f1bc2ff81e36@cornell.edu> <003701d607a0$c975f140$5c61d3c0$@gmail.com> <249be61e-da8a-7da1-ca67-0c4c6433a415@cornell.edu> In-Reply-To: <249be61e-da8a-7da1-ca67-0c4c6433a415@cornell.edu> Subject: Sv: Sv: Sv: Sv: Sv: Sv: Named pipes and multiple writers Date: Wed, 1 Apr 2020 10:52:04 +0200 Message-ID: <000a01d60802$d1525900$73f70b00$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJE9fQg8TMZuJRGwTEKbo0ZGNgDeQHtMggPA01jw/MCH/KUAAKPevBvAf/qW+kC4eksHQHeBGSzAqmcYp4CB8F8lwIBR+2oARkkbuUCauCM3AJYP32sAmYz8EcC5hrYQ6Zx7w2A Content-Language: en-gb X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 08:52:09 -0000 > 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.=A0 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.=A0 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.=A0 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.=A0 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.=A0 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.=A0 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.=A0 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:-) >=20 > 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