Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: FIFOs again
- X-seq: zsh-workers 11583
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- To: Peter Stephenson <pws@xxxxxxxxxxxxxxxxxxxxxxxxx>, zsh-workers@xxxxxxxxxxxxxx (Zsh hackers list)
- Subject: Re: FIFOs again
- Date: Thu, 25 May 2000 15:47:51 +0000
- In-reply-to: <0FV200D5BGD1A8@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
- References: <0FV200D5BGD1A8@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
On May 24, 2:34pm, Peter Stephenson wrote:
} Subject: 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 <(...).
I don't think there's a simple fix to getproc() that will handle this.
Some work is going to have to be done only when both the child process
from inside the <(...) and the one supposedly reading it have exited.
That means recording that information somewhere and dealing with it in
handler() or in the job table code.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Messages sorted by:
Reverse Date,
Date,
Thread,
Author