Applications that use glib should not invoke waitpid with a first
argument that is nonpositive, because when such a waitpid is run in
one thread and glib waits for a subprocess in another, there is a race
condition, and the former waitpid can reap a process that was intended
for the latter. Mention this in the documentation for
g_child_watch_source_new, and in the diagnostic generated by
g_spawn_sync when its waitpid fails with errno equal to ECHILD.
Signed-off-by: Colin Walters <walters@verbum.org>
http://bugzilla.gnome.org/show_bug.cgi?id=687075
* source is still active. Typically, you will want to call
* g_spawn_close_pid() in the callback function for the source.
*
- * Note further that using g_child_watch_source_new() is not
- * compatible with calling <literal>waitpid(-1)</literal> in
- * the application. Calling waitpid() for individual pids will
- * still work fine.
+ * Note further that using g_child_watch_source_new() is not
+ * compatible with calling <literal>waitpid</literal> with a
+ * nonpositive first argument in the application. Calling waitpid()
+ * for individual pids will still work fine.
*
* Return value: the newly-created child watch source
*
{
if (exit_status)
{
- g_warning ("In call to g_spawn_sync(), exit status of a child process was requested but SIGCHLD action was set to SIG_IGN and ECHILD was received by waitpid(), so exit status can't be returned. This is a bug in the program calling g_spawn_sync(); either don't request the exit status, or don't set the SIGCHLD action.");
+ g_warning ("In call to g_spawn_sync(), exit status of a child process was requested but ECHILD was received by waitpid(). Most likely the process is ignoring SIGCHLD, or some other thread is invoking waitpid() with a nonpositive first argument; either behavior can break applications that use g_spawn_sync either directly or indirectly.");
}
else
{