Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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 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/