Re: again: x11 is eating one character from stdin pipe

[Ethan M. <merritt@u.washington.edu>]

On Tuesday 21 October 2003 02:36, Petr Mikulik wrote:
> Ethan Merritt wrote>
> > Commenting out this one setvbuf() line solves 99% of the
> > problem in my tests using the awk script below.
> >
> > With the setvbuf() in place, running the awk script causes the
> > first 120+ plot commands to be lost in transit!!!!!!
> >
> > Without the setvbuf() command, only a single character is
> > dropped - the first one following the first plot command.
>
> I've tried it with Octave, but there is no change with or without
> setvbuf. Gnuplot mostly looses the first character.

Last night I built Octave 2.1.50 so that I could test this
myself. What I found is that the Octave problem and the awk
problem are not the same.

The Octave problem can, I believe, be solved with the first
patch attached below (ipc_lock.patch).  This one causes
X11_waitforinput() to refuse to read any more characters
using getc(stdin) while it is waiting for a response from the
mousing pipe.=20

This still leaves awk losing many lines of input, which is
fixed only if I also remove the call to setvbuf() as in the
second patch below (setvbuf.patch).

Applying these two patches makes both the awk and octave
test scripts run on my usual desktop machine under linux. =20

I've tested both with gnu libreadline and with the builtin
readline. But I have not yet tested on other machines, and
I would not like to commit either patch to CVS without more
extensive testing. =20

In particular I am concerned that if the response from the
mouse pipe is lost altogether, then the first patch will cause
gnuplot will hang.  I need to add some sort of timeout or
upper limit of attempts to read from the mouse pipe.


--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195