This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: Rewriting the FIFO code
- From: Ken Brown <kbrown at cornell dot edu>
- To: "cygwin-developers at cygwin dot com" <cygwin-developers at cygwin dot com>
- Date: Sat, 23 Mar 2019 15:23:02 +0000
- Subject: Re: Rewriting the FIFO code
- References: <c95425a2-59f8-f07a-6401-9609be581189@cornell.edu> <a8eee59e-81d1-18f3-d757-6bd70c484881@cornell.edu> <20181226113701.GC4061@calimero.vinschen.de> <17a43c00-ac38-e0d1-6635-d019751fbebe@cornell.edu> <20181226190305.GA3826@calimero.vinschen.de> <b5bd8bff-31a8-b6d0-1e77-62f919eceaea@cornell.edu> <20190123130547.GW2802@calimero.vinschen.de> <a8ad6d45-198e-d1f5-88ee-e9d922ecf699@cornell.edu> <20190228222337.GA20109@calimero.vinschen.de> <80fdf1ed-698a-da39-b303-ae52d64b4325@cornell.edu> <20190323102335.GY3908@calimero.vinschen.de>
On 3/23/2019 6:23 AM, Corinna Vinschen wrote:
> On Mar 22 19:27, Ken Brown wrote:
>> On 2/28/2019 5:23 PM, Corinna Vinschen wrote:
>>> For consistency it would be nice, but no, you don't have to use
>>> NT function. PIPE_NOWAIT is also available via Win32 API.
>>
>> I've finally finished a first pass at the FIFO code. I ended up
>> finding it more convenient to use the NT API and to initially create
>> pipes in blocking mode, so that I could easily wait for a client to
>> connect. After there's a connection, I set the pipes non-blocking.
>
> Sure, if that helps.
>
>> I've tested the code by running Kerrisk's server/client programs cited
>> in https://cygwin.com/ml/cygwin/2015-03/msg00047.html. I've also run
>> the test case that I posted in
>> http://www.cygwin.org/ml/cygwin/2015-12/msg00311.html.
>>
>> There's still a lot more testing that needs to be done, and I haven't
>> thought at all about the duplexer case yet, but I think I've done
>> enough that a review would be helpful when you get the time. I'll
>> send the patches to cygwin-patches shortly.
>
> Seen them, thank you. Not sure how much time I have over the weekend,
> but a first scan of your patch looks good.
>
>> Once we finish the review/revise cycle, it might make sense to commit
>> the patches to a topic/fifo branch for further work. I don't think
>> it's ready for master yet.
>
> Sounds like a plan!
>
> Here's a question: Even if you think this isn't ready for prime time,
> how much of the *old* FIFO implementation does your new code cover?
> 90%? 100%? If the code isn't quite finished from your POV, but it
> already covers all scenarios the old code (barely) worked, what
> speaks against making this a 3.1?
I'm not worried about coverage; the only thing missing that the old code covered
is the duplex case, which probably won't be difficult.
My main concern is testing. I haven't yet tested the select or fork code. But
if that works OK, then maybe this will be ready for 3.1.
Ken