[ale] Named Pipe

[Christopher Fowler]

"Advanced Programming in the UNIX Environment".

Page 446

-- [ Cut Here ] ---
When we open a FIFO, the nonblocking flag (O_NONBLOCK) affects what
happens.

1.  In the normal case (O_NONBLOCK not specified), an open for read-only
blocks until some other process opens the FIFO for writing.  Similarly,
an open for WRONLY blocks till another process opens the FIFO for
reading.

2.  If O_NONBLOCK is specified, an open for ro returns immediately.  But
and open for write-only returns an error with errno of ENXIO if no
process has the FIFO open for writing.
-- [ Cut Here ] ---

Based on that what I would do is the following:

1.  Open named pipe for reading in NONBLOCK mode
2.  Open named pipe for writing as normal.

Now simply write data to the pipe.

Now if you never have readers what happens when the pipe buffers get
full?   will your write() return an error.  If so you'll need to deal
with that.

Also note that pipe block sizes are 512 bytes.  So if you write a block
that is 1K in size it is possible that the data get mixed with any other
writers.  I just said possible.  Best bet is stick to 512bytes.  If you
have no other writers then who cares?

For those of you who do not have the Stevens library in your office I
can only say that I once I thought I knew UNIX then I read those
books.....


On Tue, 2007-03-20 at 16:50 -0400, Christopher Fowler wrote:
> On Tue, 2007-03-20 at 16:32 -0400, David Corbin wrote:
> > I have an application for which a named pipe seems like the right answer on 
> > several fronts, but what I don't want is for the writing application to block 
> > if there is noone reading it.  I just want one application to stream data to 
> > the pipe, and have some other application be able to jump in 'mid-stream' and 
> > start processing the input data.
> > 
> > Is this possible with linux named pipes?
> 
> Are you writing this code?
> 
> There is a good example of this "Advanced Programming in the UNIX
> Environment".  
> 
> Here is what you need to do.  You need to have a master process.  The
> one feeding data.  He needs to open the pipe in read mode and he needs
> to open it in write mode.  You do these operations as non-blocking.
> When you get done you can then place both file descriptors back to
> blocking mode.
> 
> When you want to feed data to the pipe simply write() data to the pipe.
> Do nothing with the read file descriptor.
> 
> 
> Why do this?  By default when you open a pipe for read or write you will
> block until someone else opens it for the opposite operation.  If you
> open for write() you'll block waiting on someone else to open on read().
> The best thing to do is have your master open up for read and open up
> for a write.  Now any other process can open up for a read and not block
> open the open() call.  They'll block like normal on the read() call.
> 
> The master app with have open'ed in non-block mode so he will not block
> in open().  
> 
> 
> Here is an example of how I did it in C
> 
>         if((pfd = open(PIPE, O_RDONLY)) == -1)
>                 log_quit("open pipe");
> 
>         if((dummyfd = open(PIPE, O_WRONLY)) == -1)
>                 log_quit("open pipe");
> 
> 
> It appears you need to open as RDONLY first then open as WRITE.  In that
> code though the master reads the pipe and sends syslog messages.  You
> can use strace to see where you are blocking in system calls.
> 
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > http://www.ale.org/mailman/listinfo/ale
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale