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 |