Unix Programming - Named pipe questions

This is Interesting: Free IT Magazines  
Home > Archive > Unix Programming > October 2005 > Named pipe questions





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author Named pipe questions
50295@web.de

2005-10-24, 3:48 pm

Hi -

Got a few questions about named pipes (NPs):

(1) Can a NP be opened for reading by more than 1 process, or for
writing by more than 1 process? e.g: 2 processes open for writing and 3
for reading. Is this possible.

(2) Are messages written to NPs buffered in the kernel? i.e. will a
sender block immiedately after writing to the NP -- untill a process
that has opened the pipe for reading does so?

Thanks,

- Olumide

Kurtis D. Rader

2005-10-24, 3:48 pm

On Sun, 23 Oct 2005 09:46:40 -0700, 50295 wrote:

> (1) Can a NP be opened for reading by more than 1 process, or for
> writing by more than 1 process? e.g: 2 processes open for writing and 3
> for reading. Is this possible.


Yes, a named pipe can have multiple writers and multiple readers. Multiple
writers is occassionally useful. Multiple readers are not since there is no
practical method for ensuring a particular reader gets a specific datum.

> (2) Are messages written to NPs buffered in the kernel? i.e. will a
> sender block immiedately after writing to the NP -- untill a process
> that has opened the pipe for reading does so?


Yes, the data is buffered. But the size of the buffer varies among
implementations. Trying to write more data than can be buffered will block
the writer (assuming, of course, you haven't set non-blocking mode).

Pascal Bourguignon

2005-10-24, 3:48 pm

"Kurtis D. Rader" <krader@skepticism.us> writes:

> On Sun, 23 Oct 2005 09:46:40 -0700, 50295 wrote:
>
>
> Yes, a named pipe can have multiple writers and multiple readers. Multiple
> writers is occassionally useful. Multiple readers are not since there is no
> practical method for ensuring a particular reader gets a specific datum.


It's practical in the case of one-byte token messages. It's a trick
used by gnu make to manage its subprocesses.

--
"Indentation! -- I will show you how to indent when I indent your skull!"
Kurtis D. Rader

2005-10-24, 3:48 pm

On Sun, 23 Oct 2005 22:55:09 +0200, Pascal Bourguignon wrote:

> "Kurtis D. Rader" <krader@skepticism.us> writes:
>
> It's practical in the case of one-byte token messages. It's a trick used
> by gnu make to manage its subprocesses.


"Trick" being the important part of that sentence :-)

Certainly there are very specialized situations where you might be able to
successfully communicate with multiple readers of a single fifo. But they
require that the readers read one, and only one, byte from the fifo. Not
just one byte per read() but one byte period. Far too big a risk from a
software maintenance perspective for my liking. There are other IPC
mechanisms that are more robust and not much more difficult to implement.
Anyone on my programming team who presented a solution that involved
multiple readers of a fifo would be encouraged to consider another line of
work :-)

Pascal Bourguignon

2005-10-24, 3:48 pm

"Kurtis D. Rader" <krader@skepticism.us> writes:

> On Sun, 23 Oct 2005 22:55:09 +0200, Pascal Bourguignon wrote:
>
>
> "Trick" being the important part of that sentence :-)
>
> Certainly there are very specialized situations where you might be able to
> successfully communicate with multiple readers of a single fifo. But they
> require that the readers read one, and only one, byte from the fifo. Not
> just one byte per read() but one byte period. Far too big a risk from a
> software maintenance perspective for my liking. There are other IPC
> mechanisms that are more robust and not much more difficult to implement.
> Anyone on my programming team who presented a solution that involved
> multiple readers of a fifo would be encouraged to consider another line of
> work :-)


Actually, IIRC, they used this because it was the most portable and
secure way to do it.

--
__Pascal Bourguignon__ http://www.informatimago.com/

Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
Alex Fraser

2005-10-24, 3:48 pm

"Kurtis D. Rader" <krader@skepticism.us> wrote in message
news:pan.2005.10.24.03.25.34.82323@skepticism.us...
[snip]
> Certainly there are very specialized situations where you might be able
> to successfully communicate with multiple readers of a single fifo. But
> they require that the readers read one, and only one, byte from the fifo.
> Not just one byte per read() but one byte period.


I could understand one byte per read(), but why "one byte period"?

Alex


Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com