|
From: <tim...@en...> - 2007-06-06 18:26:43
|
> On Wednesday 06 June 2007 08:59, Timothée Lecomte wrote: >> >> If the user asks for 'gnuplot -persist', it probably means that he's >> going >> to use the interactive screen terminal... >> Anyway, there's no problem with GNUTERM=png or if the user don't use wxt >> at all. The child process will handle it fine, because it's exactly the >> same process as the parent would be if there were no "persist" option at >> all. Meanwhile, the parent process does nothing but waits so that we >> don't >> return to the shell immediately. > > 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. > > If the parent is doing nothing but wait for the child, why do we need to > split off a child at all? > Let me try to explain again, I admit it's not straightforward: The persist behaviour is the following:"plot windows survive after main gnuplot program exits" So, the user (typically another program, maxima for example) starts 'gnuplot -persist'. It issues its commands, and then expects gnuplot to exit but the windows to remain open. We need a process to handle these windows, right ? In the x11 case: -gnuplot starts gnuplot_x11, the latter is the one that manages the windows -when gnuplot exits, gnuplot_x11 is still there until the windows are closed 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 *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. 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. 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. I hope it's clearer ;) If not, don't hesitate to ask again and I'll try to rephrase it. Best regards, Timothée |