Xref: utzoo comp.unix.questions:30855 comp.lang.c:38834 Newsgroups: comp.unix.questions,comp.lang.c Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!dog.ee.lbl.gov!elf.ee.lbl.gov!torek From: torek@elf.ee.lbl.gov (Chris Torek) Subject: Re: UNIX commands in C Organization: Lawrence Berkeley Laboratory, Berkeley References: <1991Apr28.153127.24926@jack.sns.com> <174@shasta.Stanford.EDU> Message-ID: <12610@dog.ee.lbl.gov> X-Local-Date: Mon, 29 Apr 91 13:15:41 PDT Reply-To: torek@elf.ee.lbl.gov (Chris Torek) Date: Mon, 29 Apr 91 20:15:41 GMT (Having just written a new man page for popen, I cannot resist following up, even though I should be off getting some food....) In article <174@shasta.Stanford.EDU> shap@shasta.Stanford.EDU (shap) writes: >popen(3) also has an interesting "feature." ... Et Voilla! instant deadlock. This cannot happen directly because of popen(). The reason is trivially simple: popen opens either for reading or for writing, never both. Thus popen() is unable to create a loop, and deadlock occurs only in the presence of a pipe loop. (The situation described in `...' is the simplest case, where A writes to B and then reads back from B: A->B->A. The problem also occurs in longer loops such as A->B->C->D->A.) >For those of you who don't believe this happens, talk to some people >who have had to port various window managers. These generally use bidirectional entities such as ptys and must therefore provide their own synchronization mechanisms. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov