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
Date: Thu, 10 Jan 2002 17:32:27 -0500
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: how spawn works
Message-ID: <20020110223227.GB31499@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <04a201c19a23$73ab65f0$0200a8c0 AT lifelesswks>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <04a201c19a23$73ab65f0$0200a8c0@lifelesswks>
User-Agent: Mutt/1.3.23.1i

On Fri, Jan 11, 2002 at 09:09:19AM +1100, Robert Collins wrote:
>Chris, some notes on spawn - you know it better than I, so may want to
>turn this into a .txt :}

Looks good to me.  Care to check it in?

I'm not sure what to call it, though.  "how-spawn-works" is a little
misleading.  "how-processes-are-started" is probably accurate.  I hate
for long filenames to screw up my 'ls' display, though.  :-(

cgf

>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

-- 
cgf AT redhat DOT com                        Red Hat, Inc.
http://sources.redhat.com/            http://www.redhat.com/