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: Fri, 14 Dec 2018 13:43:10 +0000
- Subject: Re: Rewriting the FIFO code
- References: <effca564-9fad-1682-e384-ea4441f85031@cornell.edu>
On 12/13/2018 6:52 PM, Ken Brown wrote:
> This is a followup to http://www.cygwin.org/ml/cygwin/2018-12/msg00104.html.
>
> On 12/11/2018 2:40 PM, Corinna Vinschen wrote
> > Perhaps the unfinished, new AF_UNIX
> > sockets code can be reused or partially duplicated to implement FIFOs.
>
> Here's my first idea. Associated to each FIFO is an abstract listener socket,
> bound to the FIFO path name preceded by NUL. This is created as soon as there's
> an attempt to open the FIFO. It acts as a communication hub for all reads from
> or writes to the FIFO. Each call to fhandler_fifo::open() creates a client
> socket that connects to the hub. The client is designated as a reader, writer,
> or duplexer, depending on how it was opened.
>
> The hub is created by a process that then monitors all the clients (via
> select()) until one is ready to read or write, as appropriate. The process runs
> as long as there are are clients connected to the hub.
>
> There are obviously many details to be worked out, but I hope the general idea
> is clear. Does this seem like a reasonable approach? Or is it unnecessarily
> complicated?
Never mind. I think I see a simpler way to achieve the same effect. I'll write
again when/if I've sorted it out.
Ken