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

[<tim...@en...>]

> On Wednesday 06 June 2007 11:26, Timothée 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
> 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".
>

Well, the child is still multithreaded with the current code, but
eventually it should be monothreaded to work reliably on wxMac.

>
>> 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.
>

My concern is backward-compatibility with current users of the persist
behaviour. I know one user, Maxima, and it's waiting for gnuplot ot finish
before continuing. Using google codesearch I can see that there are a
couple of other users of 'gnuplot -persist'. For Maxima and maybe some of
those, just closing the pipe is not enough.

Until now I have envisioned another possible use case, which is closing
the interactive shell to do something else without closing the windows.
However it is easily achievable with ctrl-z and 'bg' so it's not really
interesting.

>
>> *but* the windows must remain open. The only known solution is
>> 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
> some other synchronization method.
>
Well, as said above, I'm thinking of programs that explicitly wait for
gnuplot to exit.

But I'm open to suggestions !

Timothée