Re: buffering of process output

Re: buffering of process output

[Kim F. Storm]

I have tried your example on gnu/linux, and I can confirm your
findings for CVS emacs under X.  (I don't have 20.7)

But if I try your example with 'emacs -nw', then CVS emacs runs
smoothly too.  Wierd!!!

It seems that the difference in buffering in X vs. -nw is in the call
to emacs_read, i.e. in the call to read.  But 20.7 seems to do exactly
the same calls.

I have yet to find a sensible explanation why CVS emacs buffers output
differently with X.
 
So I wonder if X somehow causes read from a pipe to buffer things
differently [line buffering perhaps] (or the pipe to be setup
differently)?

I also tried to do (set-buffer-multibyte nil) before call-process:

- CVS emacs under X becomes much worse (seems to have to collect 16K
  output before updating)

- CVS emacs -nw still runs smoothly.

So unibyte/multibyte also kicks in somehow...

Ideas anyone ??


Kazu Yamamoto (山本和彦) <kazu@iijlab.net> writes:

> Emacs 21 has a different behavior of buffering of process output from
> Emacs 20.7.
>
> Evaluate the following in the *scratch* buffer
>
> 	(call-process "ping" nil t t "localhost")
>
> On Emacs 20.7, each line is smoothly inserted every second.
>
> On Emacs 21.3.50, however, insertion is awkward.
>
> --Kazu
>
> ----
> In GNU Emacs 21.3.50.1 (i386-unknown-netbsdelf1.6T, X toolkit, Xaw3d scroll bars)
>  of 2003-07-16 on caster.iij.ad.jp
> configured using `configure '--without-xim' '--prefix=/usr/local/emacs21' 'CFLAGS=-I/usr/pkg/include' 'CPPFLAGS=-I/usr/pkg/include -L/usr/pkg/lib' 'LDFLAGS=-R/usr/pkg/lib -L/usr/pkg/lib -R/usr/X11R6/lib -L/usr/X11R6/lib''
>

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: buffering of process output

[Andreas Schwab]

storm@cua.dk (Kim F. Storm) writes:

> So I wonder if X somehow causes read from a pipe to buffer things
> differently [line buffering perhaps] (or the pipe to be setup
> differently)?

It doesn't.  It's because there is no call to XFlush during the read loop
in call-process.  See the comment in xterm.c:

/* Remove calls to XFlush by defining XFlush to an empty replacement.
   Calls to XFlush should be unnecessary because the X output buffer
   is flushed automatically as needed by calls to XPending,
   XNextEvent, or XWindowEvent according to the XFlush man page.
   XTread_socket calls XPending.  Removing XFlush improves
   performance.  */

Thus redisplay_preserve_echo_area does not call XFlush any more.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: buffering of process output

[Kim F. Storm]

Andreas Schwab <schwab@suse.de> writes:

> storm@cua.dk (Kim F. Storm) writes:
>
> It doesn't.  It's because there is no call to XFlush during the read loop
> in call-process.  See the comment in xterm.c:
>
> /* Remove calls to XFlush by defining XFlush to an empty replacement.
>    Calls to XFlush should be unnecessary because the X output buffer
>    is flushed automatically as needed by calls to XPending,
>    XNextEvent, or XWindowEvent according to the XFlush man page.
>    XTread_socket calls XPending.  Removing XFlush improves
>    performance.  */
>
> Thus redisplay_preserve_echo_area does not call XFlush any more.
>
> Andreas.

Thanks for the explanation.  I'll fix that.

-- 
Kim F. Storm  http://www.cua.dk

Re: buffering of process output

[Kim F. Storm]

no-spam@cua.dk (Kim F. Storm) writes:

> Andreas Schwab <schwab@suse.de> writes:
>
>> storm@cua.dk (Kim F. Storm) writes:
>>
>> It doesn't.  It's because there is no call to XFlush during the read loop
>> in call-process.  See the comment in xterm.c:
>>
>> /* Remove calls to XFlush by defining XFlush to an empty replacement.
>>    Calls to XFlush should be unnecessary because the X output buffer
>>    is flushed automatically as needed by calls to XPending,
>>    XNextEvent, or XWindowEvent according to the XFlush man page.
>>    XTread_socket calls XPending.  Removing XFlush improves
>>    performance.  */
>>
>> Thus redisplay_preserve_echo_area does not call XFlush any more.
>>
>> Andreas.
>
> Thanks for the explanation.  I'll fix that.

An explicit flush doesn't fix the problem -- it may have some effect,
but output is still buffered (at least) two lines per update.

I still see cases where the display is not really updated at all
(as if redisplay doesn't see that the display need update).

I'll keep investigating.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk