Re: pgnuplot.exe flow control

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

On Monday 24 March 2008 08:48, Ralf Juengling wrote:
> On Mon, 24 Mar 2008, Tatsuro MATSUOKA wrote:
> 
> >> I don't have much experience with interprocess communication, so I don't
> >> know how these kinds of things are usually handled, but it seems like a
> >> problem that must have been solved many times over.
> >
> > It is known that data from pipe like
> > plot '-'
> > 1, 1
> > :
> > :
> > e
> > is too fast to plot for pgnuplot.
> 
> Since I work mostly on Linux, I can't say much about pgnuplot.
> But I am using gnuplot as a plotting backend as well and
> observed similar problems. My solution was to make the gnuplot
> interface bi-directional and have gnuplot work in interactive
> mode. (You need to use two pipes for that).

I find it very unlikely that the problems you report are due
to the pipe being "too fast".  It is more likely that the
issue is one of buffered/unbuffered transfer protocols.

There is also this open bug report:
  #1609845    quota limits pipe size in pgnuplot

The analysis attached to that report suggests that there is an
8K limit to the buffer for a Windows pipe. Then again, I am not
sure that the two "pipes" are really the same type of object.
Windows uses the word "pipe" to mean something other than a
Posix "pipe".  

> That said, I have begun to move to binary data transer. The
> problem seems to not occur with binary transfer, but I have
> yet to gain more experience with it.

Another option is to pass data via a separate named pipe.
From Gnuplot's point of view this is just another file.
That works fine on linux, but I have no idea whether this
is an option for Windows.


> If you want to copy this approach, have a look at
> ftp://ftp.cs.pdx.edu/pub/psu-lush/psu-lush-1.3pre8.tar.gz.
> The gnuplot interface is in file lsh/libplot/gnuplot.lsh.
> There also is a tiny gnuplot demo in the demos directory.
> 
> Ralf

-- 
Ethan A Merritt