From: sfeam <sf...@us...> - 2015-08-25 16:08:21
|
On Tuesday, 25 August 2015 11:00:42 AM Allin Cottrell wrote: > On Tue, 25 Aug 2015, Jun T. wrote: > > > 2015/08/25 12:43, Allin Cottrell <cot...@wf...> wrote: > > > >> But if I do the same thing programmatically (using the GLib function > >> g_spawn_async) the wxt window appears momentarily, with the plot > >> looking OK so far as I can tell, then disappears right away. The > >> GLib call seems to be correct; it works as intended on Linux. > >> Somehow on OS X the "pause mouse close" isn't preventing the > >> termination of the gnuplot process. > > > > I have no experience with glib, but I guess the stdin of the > > spawned gnuplot is set to /dev/null, so the gnuplot thinks it > > should quit (as if you typed ctrl-D in the terminal = EOF). > > > > On Linux, wxt window is managed by a separate process from the main > > gnuplot process. But on Mac, gnuplot+wxt is a single process, and if > > the main gnuplot quits then the plot window will go away. > Thanks, your diagnosis seems to be accurate. Unfortunately the program > from which I'm calling gnuplot is a GUI program so it doesn't have a > STDIN that gnuplot can inherit. That is true for the x11 and qt terminal drivers, which are managed by the separate processes gnuplot_x11 and gnuplot_qt respectively. Your description is not quite correct for wxt. Rather than two entirely separate processes, the wxt terminal uses either a single thread (OSX) or two threads (linux) by default. Some people have reported that they have better luck running a single thread on linux also, but that may be due to early/buggy versions of wxgtk3. > One thing I'm still not getting: you're right that g_spawn sets the > child's stdin to /dev/null by default, but then I wonder how gnuplot > stays open on Linux? As I understand it, gnuplot itself must still be > running if the 3D plot can be manipulated with the mouse. Yes. Because it is not a separate process, the main gnuplot thread stays around when the wxt terminal is in persist mode. This is unlike other terminals. The single- and multi- threaded versions use a different section of code in the routine wxt_gui.cpp: wxt_waitforinput() It sounds like there is some tweak needed for the single-threaded code block so that it doesn't exit if "pause mouse close" is active. You could try adding a check for if (!paused_for_mouse) or maybe it would need to be if ((paused_for_mouse & PAUSE_WINCLOSE) != 0) before breaking from the loop that starts at line 3869. But I'm not sure... that might cause it to hang in other circumstances. Ethan > I have found one way to get gnuplot/wxt to stay open in this context > bit it's seriously clunky: write out a shell script that calls gnuplot > with the plot-script argument, then use system() to call Terminal.app > to execute the shell script. The Terminal.app window is just in the > way and doesn't close itself on exit. > > > > > You may try setting the G_SPAWN_CHILD_INHERITS_STDIN bit in the > > 'flags' (the 4th arg of g_spawn_async()), so that the gnuplot will > > inherit the stdin from the parent. > > > Allin Cottrell > > > > ------------------------------------------------------------------------------ > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta |