Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: FIFOs again



Andrej wrote:
> > Yes, I got the same. Real nasty. One possibility is "dummy open" in
> > parent. The child hangs because it tries to open FIFO without
> > counterpart. Parent can simply open it and then close when child exits
> > or we're done with current commmand (it currently have to delete FIFO
> > anyway).
> >
> 
> Actually, it seems to be possible to immediately close it. The following
> trivial change to getproc() (marked with >>>>>>) seems to do the trick
> (no more hung processes).

I don't think this does the right thing.  Consider <(...).  The child
process successfully opens the pipe for writing when the parent opens it
for reading.  Now the parent closes it.  But meanwhile the child process
has been busy, and when it finds the file is closed again it either gets
SIGPIPE or a write failure on the fd and gives up --- unless the new
command has opened it in the meanwhile, but that's unlikely (and you need
it to be certain).  I tried with

  cat <(echo foo)

and confirmed that it's the cat which hangs forever, waiting for something
to open the other end of the pipe for writing.  At least that's what seems
to be happening with Solaris 2.6.

Keeping the process open in the parent might work, however (there's a
slight extra subtlety over your code that we need to check the fork
returned a positive value).  We would have to make quite sure of closing it
when we delete the file --- leaving a temporary file name around isn't a
big problem, but a file descriptor leak is.  Also, I'm not quite sure of
the issues behind having both the shell itself and the command which gets
the file name having fd's open to the same file, though I can't offhand see
a case where it would cause a problem since we never read from or write to
it.  But I don't think it's a good idea to rush into this at the last
minute before 3.1.7.  If someone can definitely answer those two points
(the first is internal, the second an OS matter) there's no reason why we
couldn't add this eventually.

-- 
Peter Stephenson <pws@xxxxxxxxxxxxxxxxxxxxxxxxx>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070



Messages sorted by: Reverse Date, Date, Thread, Author