Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Message-ID: <04a201c19a23$73ab65f0$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin-developers AT cygwin DOT com>
Subject: how spawn works
Date: Fri, 11 Jan 2002 09:09:19 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 10 Jan 2002 22:09:18.0102 (UTC) FILETIME=[72A4CB60:01C19A23]

Chris, some notes on spawn - you know it better than I, so may want to
turn this into a .txt :}

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.

Rob