On Dec 18 11:54, Warren Young wrote: > On Dec 18, 2014, at 11:51 AM, Corinna Vinschen <corinna-cyg...@cygwin.com> > wrote: > > > On Dec 18 11:40, Warren Young wrote: > >> On Dec 18, 2014, at 10:33 AM, Corinna Vinschen <corinna-cyg...@cygwin.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 -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgpN6ki0mmEXE.pgp
Description: PGP signature
