rvp@softserver.canberra.edu.au (Rey Paulo) (05/24/91)
Assume I have created a pipe in my C program. Assume further that one end of the pipe is to be written to by a child process while the other end is to be read from by the parent process. What I am wondering is this. Suppose if the child has written something into the pipe and exited, could the parent still read what has been written by the child from the reading end of the pipe even if the child is already dead? -- Rey V. Paulo | Internet: rvp@csc.canberra.edu.au University of Canberra | I am not bound to please thee with my answer. AUSTRALIA | -Shylock, in "The Merchant of Venice" ------------------------------+----------------------------------------------
gwyn@smoke.brl.mil (Doug Gwyn) (05/25/91)
In article <1991May24.025917.18874@csc.canberra.edu.au> rvp@softserver.canberra.edu.au (Rey Paulo) writes:
-Suppose if the child has written something into the pipe and exited,
-could the parent still read what has been written by the child
-from the reading end of the pipe even if the child is already dead?
Sure, unless somebody has badly broken your implementation of UNIX.mouse@thunder.mcrcim.mcgill.edu (der Mouse) (05/30/91)
In article <16262@smoke.brl.mil>, gwyn@smoke.brl.mil (Doug Gwyn) writes: > In article <1991May24.025917.18874@csc.canberra.edu.au> rvp@softserver.canberra.edu.au (Rey Paulo) writes: >> Suppose if the child has written something into the pipe and exited, >> could the parent still read what has been written by the child from >> the reading end of the pipe even if the child is already dead? > Sure, unless somebody has badly broken your implementation of UNIX. On a similar note, I find that Sun seems to have broken ptys along similar lines in recent releases (ie, >=4.0): if the slave side has experienced its last close, any buffered data is thrown away after some delay[%], even when the parent side is kept open more or less indefinitely. (This causes problems with our local emacs variant; when it's suspended with a compile going, compile output is lost if it isn't resumed before or soon enough after the compile finishes.) Grrr. Works fine on 3.5 and real BSD. [%] The delay is more than about fifteen seconds but less than a few minutes. I haven't bothered to pin it down more precisely. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
libes@cme.nist.gov (Don Libes) (05/30/91)
In article <1991May30.093934.27121@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes: >[Sun 4.x has broken ptys - if slave side is closed, buffered data is >thrown away after some delay ... (This causes problems with our local >emacs variant; when it's suspended with a compile going, compile output >lost if it isn't resumed "soon enough" after the compile finishes.)] Sun, AT&T, and others know about this. (I know, I called a few.) I never did get what I felt to be a satisfactory answer. The most plausible suggestion was that this is a "feature" to lessen the likelihood of inadvertently opening a new slave while an old master is still active. (Hard to believe, isn't it?) Fixing this flaw requires fixing the usual pty kludges related to protection and allocation. >[%] The delay is more than about fifteen seconds but less than a few > minutes. I haven't bothered to pin it down more precisely. On Suns the interval is indeed 15 seconds. Even worse is the Cray which throws away unread data IMMEDIATELY upon slave close. Don Libes libes@cme.nist.gov ...!uunet!cme-durer!libes
merlyn@iWarp.intel.com (Randal L. Schwartz) (05/30/91)
In article <3577@muffin.cme.nist.gov>, libes@cme (Don Libes) writes: | On Suns the interval is indeed 15 seconds. Even worse is the Cray | which throws away unread data IMMEDIATELY upon slave close. Which proves that *nothing* takes 15 seconds on a Cray. :-) Just another cray-user-wannabe, -- /=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ==========\ | on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III | | merlyn@iwarp.intel.com ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn | \=Cute Quote: "Intel: putting the 'backward' in 'backward compatible'..."====/