Re: wxt and "persist", n-th iteration !

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

On Wednesday 06 June 2007 11:26, Timoth=E9e Lecomte wrote:
> Ethan Merritt wrote
> > I guess I'm dense today.  I don't understand.
> > I thought that this whole parent/child split was because the parent
> > process had to be the one managing the plot window.

Ah, I missed the subtlety that you had shifted from threads to=20
separate processes.  So the deal is that a child process can manage
the plot window so long as it is done in the "parent thread of the
child process".=20

> The persist behaviour is the following:"plot windows survive after main
> gnuplot program exits"

> In the wxt case:
> -gnuplot handles the windows without the help of another program. To
> satisfy the caller program, it *has* to exit when the commands have all
> been issued

I don't think this is true.  Why can't gnuplot simply close the pipe
back to the calling program, but continue running with no further
input?  That is essentially what gnuplot_x11 does.

When the calling program sees that the pipe has closed, it continues
on with whatever it wants to do next.  It shouldn't be necessary that
the gnuplot process itself has terminated.

> *but* the windows must remain open. The only known solution is=20
> to fork(), exit the parent (so that the calling program will be able to
> continue) and let the child handle the windows.

I can think of several other solutions that do not involve fork().
If you don't like the pclose() solution, explain why and I'll suggest=20
some other synchronization method.

	Ethan


> The next question is: when to fork() ?
> At exit-time ? The problem is that the windows are already created, so
> they somehow have to be "transfered" to the child process. It's possible
> on X (but tricky), however I think it's impossible on MacOS (or much
> trickier).
> So we have to fork() at startup, and let the child do *everything*, from
> readline to drawing, including command-line parsing.
> The parent becomes a dummy program which is just there to simulate what
> would be gnuplot itself in the x11 case.
>=20
> For example, with this scheme, if you do on the shell:
> 'gnuplot -persist'
> -> immediately, a child is forked, where everything is done. The parent
> sits there so that the shell doesn't return, and only for that.
>=20
> I hope it's clearer ;) If not, don't hesitate to ask again and I'll try to
> rephrase it.
>=20
> Best regards,
>=20
> Timoth=E9e
>=20
>=20
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>=20

=2D-=20
Ethan A Merritt