Mail Archives: cygwin/2004/11/12/10:43:07
On Fri, Nov 12, 2004 at 05:29:45PM +0200, Kamen TOMOV wrote:
>On Fri, Nov 12 2004, Dave Korn wrote:
>
>> Waittaminnit. You're saying that the spawned processes _aren't_
>> cygwin processes?
>>
>> Well then you're entirely barking up the wrong tree. Cygwin can't
>> magically make win32 programs signal-aware. The issue of not having
>> a pid for it is utterly irrelevant.
>>
>> OTOH, I think if you were to spawn them under a shell, rather than
>> by fork-and-exec, you would probably be able to kill the children by
>> killing the shell, in much the same way as if you're running in bash
>> and you run cmd.exe at the command line you can then kill it and
>> return to the shell by pressing ctrl-c. Which doesn't usually kill
>> cmd.exe, but when it's launched as a child of a cygwin shell, works
>> fine.
>
>That's a great idea. I'll stick with it and will rewrite the
>application to start the daemons from the cygwin's shell. That would
>make my life much easier because instead of rewriting the cygwin's
>fork function to register processes in its own virtual table (although
>I do not know if that is possible) they would be instantly
>available. It was strange to me that fork do not make them appear
>there but anyway... thank you very much!
I can't shake the feeling that we are dancing around a misconception
here somewhere.
The bash shell doesn't do anything magical when it starts processes. If
you are using cygwin's fork then you shouldn't be worrying about
"windows pids". If you are running a cygwin program which uses fork and
exec then the processes that it creates are cygwin processes and you
will be able to manipulate them using normal UNIX functions.
If you are calling cygwin_winpid_to_pid on a pid that you got from
a fork(), or spawn*() call then that is not right.
cgf
--
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 -