Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
From: Christopher Faylor <cgf AT cygnus DOT com>
Message-ID: <19990207230759.A11115@cygnus.com>
Date: Sun, 7 Feb 1999 23:07:59 -0500
To: jmm AT raleigh DOT ibm DOT com, cygwin AT sourceware DOT cygnus DOT com
Subject: Re: pid problem found
References: <199902080327 DOT WAA24699 AT jmm DOT raleigh DOT ibm DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <199902080327.WAA24699@jmm.raleigh.ibm.com>; from jmm@raleigh.ibm.com on Sun, Feb 07, 1999 at 10:27:07PM -0500

On Sun, Feb 07, 1999 at 10:27:07PM -0500, jmm AT raleigh DOT ibm DOT com wrote:
>Ok, this may still be a B20.1 problem, but I'm definitely more shaky
>about it now.  It turns out that after CreateProcess, the returned
>PROCESS_INFORMATION structure has a dwProcessId entry that's usally
>between 3 to 5 times the value of the real pid.

There is absolutely no relationship between the dwProcessId returned by
CreateProcess and a cygwin pid.  Cygwin pids are generated by the DLL.

We can't use the Windows pid because Windows doesn't support anything
like the exec() function.  So, we have to enforce our own pids
independently of Windows.

If you want to use cygwin functions to wait for pids you'll have to use
cygwin functions to create processes as well.

>for instance, the spawned child's real PID will be 1070, but 
>the dwProcessId will give 3919... the next run, real PID is 1072, 
>but dwProcessId gives 4663, a third time real is 1075, dwProcessId
>returns 3033.
>
>(I've been using dwProcessId to save the pid for later waitpid() calls,
>which now explains why those were failing)

-- 
cgf AT cygnus DOT com
http://www.cygnus.com/

--   
Want to unsubscribe from this list?                             
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com