Re: g_spawn_sync and child PID
Le 15/03/2014 21:19, Allin Cottrell a écrit : > I'm reasonably familiar with the usage of both g_spawn_sync and > g_spawn_async, but recently I've found myself wanting to do domething > that seems to fall between the two and I can't quite work out how to do it. > > Here's the task: I want to spawn an mpiexec process from my GTK app and, > assuming all goes well, wait for the result (in itself that's a case of > g_spawn_sync). But I also want to know the PID of mpiexec, so that I can > give the user the option of killing that process "prematurely" if it > seems to be going wrong. (This is based on the observation that an > MPI_Bcast call, for example, can hang at 100% CPU if one or more of the > processes launched by mpiexec bombs out at just the wrong moment.) > > Any suggestions on how to achieve this using g_spawn* (or judgements on > whether it's even possible) would be gratefully received. If you need any user interaction, you probably need an asynchronous spawn anyway, so you need to use g_spawn_async() and use g_child_watch_add() to get notified when the child quits. But since this is asynchronous, your program have to handle the case stuff happens when the process is running (like click on a cancel button, but also anything else). Also, how complex it'd be will depend on whether you need to write to the child's stdin and/or read from its stderr/stdout. If you open the pipes, you *have* to make sure none ever gets full, which would block the child. This means you have to also asynchronously read and write to the child. If you don't communicate with the subprocess however, it's only a matter of waiting for the child asynchronously to let the UI interact with the user, and that's pretty easy as explained above. BTW, GLib spawn API also lacks a portable way to kill the subprocess, so one has to manually use platform-specific API like kill() or TerminateProcess() -- not hard to do, but has to be done. Anyway, since all this can be tricky, I suggest you to try and use the brand new GIO GSubprocess API if you can, it does all the tricky job itself (and has API to kill the subprocess :) -- but it's still unreleased https://developer.gnome.org/gio/unstable/GSubprocess.html. Regards, Colomban ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
g_spawn_sync and child PID
I'm reasonably familiar with the usage of both g_spawn_sync and g_spawn_async, but recently I've found myself wanting to do domething that seems to fall between the two and I can't quite work out how to do it. Here's the task: I want to spawn an mpiexec process from my GTK app and, assuming all goes well, wait for the result (in itself that's a case of g_spawn_sync). But I also want to know the PID of mpiexec, so that I can give the user the option of killing that process "prematurely" if it seems to be going wrong. (This is based on the observation that an MPI_Bcast call, for example, can hang at 100% CPU if one or more of the processes launched by mpiexec bombs out at just the wrong moment.) Any suggestions on how to achieve this using g_spawn* (or judgements on whether it's even possible) would be gratefully received. -- Allin Cottrell Department of Economics Wake Forest University, NC ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Reshowing Icons in a Grid (Andrew Potter)
I have 10 different icons stored in 10 files. I want to display these 10 icons in different locations in a gtk_grid_new(). It works fine once. If I gtk_widget_destroy(grid), create a new grid, and try to display these 10 icons a second time (some in different grid locations and some not) I get gtk_grid_attach: assertion `gtk_widget_get_parent (child) == NULL' failed and several gtk_grid_attach: assertion `GTK_IS_WIDGET (child)' failed However, if I re-load the icons from their files after gtk_widget_destroy(grid) it works fine the second time. Most widgets are "floating" on creation. Then when you add them to a container they get sinked. When you destroy the grid, it unrefs all its children before it is destroyed. If that is the only reference your icons, they are destroyed as well. You can g_object_sink_ref(your_icon) after you create them the first time, then you should be able to add them to new containers after they are destroyed. That's the ticket! Thanks. One minor change ... it should be g_object_ref_sink() rather than g_object_sink_ref(). -- Marshall Lake -- ml...@mlake.net -- http://www.mlake.net ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
