regarding helper process in GLib 2.8.4
- Date: Wed, 25 Jan 2006 13:03:21 +0200
- From: Tor Lillqvist <tml@xxxxxx>
- Subject: 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*()
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.
gtk-list mailing list