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
X-WM-Posted-At: avacado.atomice.net; Tue, 28 May 02 23:50:41 +0100
Message-ID: <00fc01c2069a$17e09680$0100a8c0@advent02>
From: "Chris January" <chris AT atomice DOT net>
To: <cygwin-developers AT cygwin DOT com>
References: <008601c2068e$193b6200$0100a8c0 AT advent02> <20020528223943 DOT GA18086 AT redhat DOT com>
Subject: Re: Question about process enumeration and _pinfo structure
Date: Tue, 28 May 2002 23:50:41 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000

> >I want to add a member to the _pinfo structure which contains the command
> >line originally passed to the process. At the moment, when the Cygwin DLL
> >needs a list of the current Cygwin processes it uses winpids to enumerate
> >the processes and the _pinfo structures for each Cygwin process are
copied
> >from a named file mapping. So to store the command line I either need to:
> >i) make the command line an in-line array, e.g. char cmdline[1024];
> >or
> >ii) make the member a pointer to a string allocated on the cygwin heap.
>
> I'm not wild about either idea.  The reason there is no command line in
> the pinfo structure is because I didn't want to waste shared memory space
> on something that was rarely used.  I also didn't want to have to recreate
> the command line in dll process startup.
A third alternative is to get the information from the process environment
block. However this is NT specific and doesn't handle fork'ed processes. I
don't understand why you would need to recreate the command line in dll
process startup though. So is any solution preferred or shall I just drop
the idea of /proc/<n>/cmdline ?

Chris