Mail Archives: cygwin/2009/04/24/03:27:39
>>>>>> Hi, I'm new to cygwin, and I am beginning to like it. I am having
>>>>>> trouble
>>>>>> though with child processes that have only Windows PIDs and not
>>>>>> cygwin
>>>>>> PIDs.
>>>>>>
>>>>>> When I run Xilinx bitgen from cygwin 2 processes are run both with
>>>>>> the
>>>>>> name
>>>>>> bitgen.exe. Below I am running bitgen through make.
>>>>>>
>>>>>> PID PPID PGID WINPID TTY UID STIME COMMAND
>>>>>> S 3936 2836 3936 2380 0 12696 19:54:49
>>>>>> /usr/bin/make
>>>>>> S 808 3936 3936 2852 0 12696 19:54:49
>>>>>> /cygdrive/c/Xilinx/10.1/ISE/bin/nt/bitgen
>>>>>> 2852 0 0 2852 ? 0 19:54:49
>>>>>> c:\Xilinx\10.1\ISE\bin\nt\bitgen.exe
>>>>>> 504 0 0 504 ? 0 19:54:49
>>>>>> c:\Xilinx\10.1\ISE\bin\nt\unwrapped\bitgen.exe
>>
>>> Since I'm not sure what Xilinx is doing, I can't really say. Someone
>>> else
>>> here *might* be able to tell you, if they have run into the same thing
>>> either with Xilinx or some other native Windows app. But since this
>>> probably has more to do with Xilinx's particular implementation and less
>>> to do with Cygwin proper, this would be off-topic for this list. That's
>>> one of the reasons why I was suggesting talking to the Xilinx folks.
>>> That
>>> and the fact that they should know exactly what they're doing, why, and
>>> how you might track it.
>>
>> Not entirely - the problem being that pstree always uses Cygwin PIDs
>> which are not necessarily the same as WINPIDs - it would be quite useful
>> if pstree had an option to display Windows PIDs.
>>
>> (In fact, I had to rewrite the PIDs in my pstree output of the git-svn
>> report on this list some hours earlier to the winpids to match the
>> sysinternals handle output...)
>
> And that's benefit of open source. :-) Perhaps you'd want to prepare
> a patch that you can offer to the upstream 'psmisc' maintainers to see if
> they want to incorporate your solution to your "itch". If not and if all
> you need is something to tell you what the Windows PID is for a particular
> Cygwin PID, you do have 'ps' as well, as you've noted above. It's also
> worthwhile to note that Cygwin PIDs differ from Windows PIDs only when
> there
> is a need to 'fork'. Since Windows doesn't do this and 'bitgen' is
> clearly
> a Windows app, the "two" PIDs will match in this case and will be the
> Windows PID, if that helps you.
Regarding forking - you can see from my first post that bitgen is spawning a
new process / PID and there is no way that I've found within cygwin to
identify which program is the parent of the new fork. PID 504 is the new
forked bitgen, and it has 0s for the PPID and PGID entries. The original
bitgen process appears twice under ps -W and they are clearly the same
process as can be seen from the WINPID in both processes. The reason I want
to know programmatically who the parent of the new bitgen process is so that
I don't end up killing a second parallel compilation.
I think part of the problem is that ps only lists one copy of bitgen, and
the only way to see the second bitgen is with ps -W. Somewhere cygwin is
losing track of bitgen's spawned process and therefore it's not showing up
with just ps.
--
View this message in context: http://www.nabble.com/pstree-on-windows-xp---find-process-spawned-from-windows-process-tp23197461p23211293.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -