Thu Dec 18 19:10:00 GMT 2014
On Dec 18 11:54, Warren Young wrote:
> On Dec 18, 2014, at 11:51 AM, Corinna Vinschen <firstname.lastname@example.org> wrote:
> > On Dec 18 11:40, Warren Young wrote:
> >> On Dec 18, 2014, at 10:33 AM, Corinna Vinschen <email@example.com> wrote:
> >>> On Dec 18 10:26, Warren Young wrote:
> >>>> ...Cygwin doesn’t do something similar?
> >>> Cygwin isn't a kernel and the process
> >>> information is kept in shared memory regions held by the parent process
> >>> and the process itself. This model has limitations you don't have on a
> >>> real kernel.
> >> I’m aware of that, but can’t the DLL see both the birth and death of
> >> every Cygwin process? Birth via either DllMain() or execvp(2), and
> >> death via one of the methods here:
> > Aren't we talking about fetching info from non-Cygwin processes?
> Of course. But if you keep a table of all Cygwin processes, you can
> tell whether you’re being asked for info for a native process vs a
> Cygwin one, and handle <defunct> differently for the two cases.
That may be possible, but it's just not implemented. Under the hood,
the process your seeing in /proc is not really the native Windows
process, but rather a Cygwin process stub. The stub has a process info
shared mem region, but it's essentially defunct, the only task it's
handling is to wait for the non-Cygwin process to exit. It may be
possible to add functionality to the stub process, but given that the
actually running process is a non-Cygwin process, it will be fairly
limited. And, seriously, there was just no reason to put that much
work into bookkeeping for native processes.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Cygwin