From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 781 invoked from network); 24 May 2000 13:34:54 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 24 May 2000 13:34:54 -0000 Received: (qmail 5349 invoked by alias); 24 May 2000 13:34:44 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11558 Received: (qmail 5341 invoked from network); 24 May 2000 13:34:44 -0000 Date: Wed, 24 May 2000 14:34:14 +0100 From: Peter Stephenson Subject: Re: FIFOs again In-reply-to: "Your message of Wed, 24 May 2000 16:43:28 +0400." <000101bfc57d$a8c80d50$21c9ca95@mow.siemens.ru> To: zsh-workers@sunsite.auc.dk (Zsh hackers list) Message-id: <0FV200D5BGD1A8@la-la.cambridgesiliconradio.com> Content-transfer-encoding: 7BIT 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 Cambridge Silicon Radio, Unit 300, Science Park, Milton Road, Cambridge, CB4 0XL, UK Tel: +44 (0)1223 392070