|
From: Andreas D. <qu...@ma...> - 2001-02-09 10:24:41
|
Hello.
I'm working on a little python module to provide interactive plotting
capabilities. Currently I have the following problem.
The xwin driver will not start redrawing the window before plend() is
called. Now the problem is, plend() will block until the window is closed (as
expected). I considered the following solutions:
a)Fork whenever a plot has to be drawn.
Easy, but has a catch, as illustrated in this example: User has a big dataset
(50Mb, 100Mb or more) in core. He tries something, generates a plot. In this
implementaion the interpreter will fork, inheriting all of the fathers core
(Thanks to copy-on-write this does not immediatly mean that memory demand
doubles). User is not satisfied and tries some more things, in the end
having 6 plot windows open, each handled by a seperated process which
inherited the big data set from its father. Now imagine user scraps the
dataset (say, by reloading from disk): thanks to copy-on-write the OS will start
to look for memory to provide 6 useless copies of data to all those
plot-processes. Not good.
b) Fork a plotter on startup. Send commands and data to it via IPC. Let it
fork more processes do handle each window. No obvious problems, but needs a
IPC mechanism to be designed and implemented.
c) Generate immediate plmeta-represenation in the main process and
fork()/exec(plrender) to display it. This could even provide interactive
data readout via fifo. Drawback: plrender cannot read from a pipe or a
fifo(fgetpos fails). This means
+ temporary files have to created
+ An existing plot-window cannot be updated or reused. Plrender will read
to EOF and then wait for the window to be closed.
I really like c) because of its simplicity and because it is _almost_
working as I want. Now if just plrender could read from a fifo.
Looking at plmeta.c it seems that writing to a pipe was considered (but not
finished, at least one more if(isfile) is needed), so it may be possible to
patch plrender to work from a pipe (perhaps losing a feature or two), but I
do not yet understand the code good enough. Does anybody out there
understand the design of plmeta files?
Any other comments?
thanks. Andreas
To get the plmeta driver to _write_ to a pipe only a minimal change was needed
--- plplot/drivers/plmeta.c.bak Thu Feb 8 13:50:45 2001
+++ plplot/drivers/plmeta.c Thu Feb 8 13:56:01 2001
@@ -622,6 +622,7 @@
WriteFileHeader(PLStream *pls)
{
PLmDev *dev = (PLmDev *) pls->dev;
+ int isfile = (pls->output_type == 0);
FILE *file = pls->OutFile;
dbug_enter("WriteFileHeader(PLStream *pls");
@@ -631,10 +632,10 @@
/* Write file index info. Right now only number of pages. */
/* The order here is critical */
-
- if (pl_fgetpos(file, &dev->index_offset))
- plexit("WriteFileHeader: fgetpos call failed");
-
+ if (isfile) {
+ if (pl_fgetpos(file, &dev->index_offset))
+ plexit("WriteFileHeader: fgetpos call failed");
+ }
plm_wr( pdf_wr_header(pls->pdfs, "pages") );
plm_wr( pdf_wr_2bytes(pls->pdfs, (U_SHORT) 0) );
--
"We've heard that a million monkeys at a million keyboards could produce the
complete works of Shakespeare. Now, thanks to the Internet, we know this is not
true." -- Robert Wilensky
|