blob: e4e25eae99ae87414ae012912f465e5bfde0464b (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
|
Spawn.cc in cygwin handles spawn, vfork and exec calls. It does this via
a mode parameter that determines its behaviour with respect to the
child.
Of particular interest is the exec behaviour.
In general spawn_guts (where the action happens) does the following:
* Finds the actual program being run (which may include path searching).
* Determines the type (.exe, shell script, perl etc) and for non binary
programs finds the correct interpreter.
* Creates a commandline (based on the type and the user parameters).
* Guesses at whether the binary that will be invoked is a cygwin program
or not (if (real_path.iscygexec ())) and uses that information to copy
the argv table, or to translate it for win32 program usage.
* passes a handle to the parent to the child (note: this handle should
have it's rights restricted the daemon is merged).
* Start the process.
* if the mode is _P_OVERLAY (we are doing an exec)
wait for the child to
a) if it's a cygwin process, signal us via an event.
b) if it's a win32 process, exit.
c) exit.
If a) occurs, we 'reparent' the child which makes it look to the current
process's parent in the pid and process group chains.
b) is where the cygwin process hangs around as a 'stub' presenting it's
pid as the win32 process's pid, to allow cygwin tools to kill the win32
process.
once a-c has occured, execution resumes.
* If the mode is _P_OVERLAY, this process exits, otherwise it's
behaviour depends on the mode parameter. See the last block of
spawn_guts.
|
