Question about process enumeration and _pinfo structure

[Christopher Faylor]

On Tue, May 28, 2002 at 10:24:49PM +0100, Chris January wrote:
>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.

>The first would work, but would set a limit on the size of command line. (I
>believe there are several other, conflicting, limits elsewhere so this
>shouldn't be a problem).
>The second would also work, but would tie the _pinfo structure to a specific
>instance of the Cygwin DLL.
>Now I know there's supposed to be only one instance of the DLL running on
>the system anyway, which leads me to the following question:
>Why are the processes enumerated in this fashion rather than an array or
>linked list of _pinfo's stored in the shared_info structure? Is this just
>historical (i.e. noone got round to changing it) or is there some reasoning
>behind it?

Cygwin used to maintain a linked list but there were synchronization issues
every time a process got added or removed.  And, if a process died without
going through do_exit it stuck around as a zombie forever.

Moving to just trying to use windows pids where possible solved that problem.
The only time it is an issue, AFAIK, is when you are trying to find other
processes in your process group.  That is more expensive now than it used
to be.

cgf