Web lists-archives.com

regarding helper process in GLib 2.8.4




Sumit Kumar Jain writes:
 > I was going through the GLib 2.8.4 code and while reading the file
 > gspawn-win32.c I saw that a helper process is required in case of
 > windows, while no such process is requied for LINUX. I want to know
 > why is such a mechanism required.

Basically, because Win32 doesn't have fork().

As the comment in gspawn-win32.c says:

/*
 * Implementation details on Win32.
 *
 * - There is no way to set the no-inherit flag for
 *   a "file descriptor" in the MS C runtime. The flag is there,
 *   and the dospawn() function uses it, but unfortunately
 *   this flag can only be set when opening the file.
 * - As there is no fork(), we cannot reliably change directory
 *   before starting the child process. (There might be several threads
 *   running, and the current directory is common for all threads.)
 *
 * Thus, we must in most cases use a helper program to handle closing
 * of (inherited) file descriptors and changing of directory. The
 * helper process is also needed if the standard input, standard
 * output, or standard error of the process to be run are supposed to
 * be redirected somewhere.
 *
 * The structure of the source code in this file is a mess, I know.
 */

If we used CreateProcess() directly instead of the C library spawn*()
functions, the working directory could be set. But the handling the C
file descriptor inheritance and argument vector serialization into a
command line would require essentially duplicating much of the code in
the C runtime.

Sure, the C runtime sources are included with the MSVC compiler (and I
have a legal license), and you can even find them on the net... But
using knowledge gleaned from the C runtime source code would be of
dubious legality. Microsoft can claim that the undocumented method
they use to pass inherited C file descriptor -> Win32 file handle
mapping is a trade secret. It's safer to just use the spawn*()
functions.

And, if we used CreateProcess() directly, the underlying Win32 file
handles would be inherited anyway, even if the corresponding C file
descriptors wouldn't be. When the helper process closes the inherited
C file descriptors that shouldn't be inherited, the Win32 file handles
get closed (in the helper process), too.

--tml

_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list