Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!princeton!allegra!mit-eddie!mit-trillian!wesommer
From: wesommer@mit-trillian.MIT.EDU (William Sommerfeld)
Newsgroups: net.emacs
Subject: Re: Inferior process violates gnuemacs 1st ammendment?
Message-ID: <1016@mit-trillian.MIT.EDU>
Date: Fri, 15-Aug-86 13:08:02 EDT
Article-I.D.: mit-tril.1016
Posted: Fri Aug 15 13:08:02 1986
Date-Received: Sun, 17-Aug-86 08:37:32 EDT
References: <1508@mcc-pp.UUCP>
Reply-To: wesommer@mit-eddie.UUCP (William Sommerfeld)
Organization: MIT Project Athena
Lines: 54
Keywords: hot-shots, pipes, send-region, deadlock

Read the manual page for pipe(2) (this is BSD 4.3, but it hasn't
changed much).

     The pipe system call creates an I/O mechanism called a pipe.
     The file descriptors returned can be used in read and write
     operations.  When the pipe is written using the descriptor
     fildes[1] up to 4096 bytes of data are buffered before the
     writing process is suspended.  A read using the descriptor
     fildes[0] will pick up the data.

BUGS
     Should more than 4096 bytes be necessary in any pipe among a
     loop of processes, deadlock will occur.

In article <1508@mcc-pp.UUCP> tiemann@mcc-pp.UUCP writes:
>
>Here's the problem: we set up at "cat" process (copy input to output),
>find a big file, set point and mark to be 1000 characters apart, and
>they repeatedly type "ESC-$" . 
>
>On our SUN-3 about the 4th "ESC-4" the error message "writing to process:
>operation would block, cat" pops up. If we continue to type "ESC-$",
>the error sometimes comes up, and sometimes does not. On our VAX
>11/750 "running" (walking) BDS 4.2, there is no error message, but the
>gnuemacs shows up as Idle in ps -ux. (A few ^G's wake it into
>abortion-land).

It looks like you're jamming more than the maximum buffer size into
the pipe.  Since all "cat" does is whip your input back out at you,
and Emacs hasn't had a chance to read it yet, when both buffers get
jammed, you lose and have to break out.  It is possible that the SUN
kernel detects this deadlock situation and returns an EWOULDBLOCK
("Operation would block") error code.

>It seems to me that if I want to write a zillion bytes to a pipe, and
>somebody else wants to read it, that the OS should wake and sleep us
>until those zillion bytes have zipped through the pipe. If this is an
>incorrect interpretation, please tell me how to pretend this is
>happening.

Not if the kernel limits your buffer space; otherwise, runaway
processes could chew up all your memory.  The problem is not that
you're shipping a lot through the pipe, it is that you're shipping a
lot through, it's being sent right back to you, and you have no way to
read it because you're writing right now.

A possible fix (BSD dependant) would be to select non-blocking I/O,
maintain a queue of input for each file descriptor, and then ship
things over in 1K or 2K chunks, and drop back into a select loop when
the operation blocks.

					Bill Sommerfeld
				  ARPA: wesommer@athena.mit.edu
				  UUCP: ...!mit-eddie!wesommer