basic C question
fcsoft-3Emkkp+1Olsmp8TqCH86vg at public.gmane.org
Tue Jul 13 16:18:10 UTC 2004
I did some reading myself and repeated my fifo experiments with O_RDONLY and
O_WRONLY and sure enough the SIGPIPE happens. If you catch and ignore the
SIGPIPE you can make the write() return a -1.
Unfortunately, when you open a fifo O_RDONLY and the other end isn't yet
opened for writing the open() call blocks. This little tidbit makes a
mess of any select() logic one wants to initialize around that file
Thanks again for all your advice.
Seems like in this case you are damned if you do and damned if you don't ...
but I'll keep plugging ...
On July 12, 2004 05:23 pm, you wrote:
> On Mon, 12 Jul 2004 fcsoft-3Emkkp+1Olsmp8TqCH86vg at public.gmane.org wrote:
> > Once again if process A (the reader) creates the named pipe and process B
> > (the writer) opens a file descriptor to that pipe there appears to be no
> > way to detect that process A (the reader) has vanished. ie. the
> > write() will always succeed.
> It shouldn't; normally, the writing program will get blown away by a
> SIGPIPE signal in that case.
> However, you have to be careful about some details. Notably, the writing
> program must open it for writing *ONLY*. If it opens it for both read and
> write, then the fifo *is* open for reading even with no other process
> involved, and so there's nothing wrong with doing a write() to it.
> (It is actually possible, although rarely sensible, for the same program
> to both read and write a fifo.)
> Similarly, if any of the programs involved is using fork() and suchlike,
> remember that fork() duplicates all file descriptors, so some uninvolved
> process may still have a copy of that file descriptor. (This is a classic
> mistake in using regular pipes.)
> Henry Spencer
> henry at spsystems.net
The Toronto Linux Users Group. Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml
More information about the Legacy