This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: GUI Config tool 2.04 bug (REPRODUCEABLE) - notclosing child process


>>>>> "Jifl" == Jonathan Larmour <jlarmour@redhat.com> writes:

    Jifl> Julian Smart wrote:
    >> 
    >> At 09:08 AM 8/13/01 -0600, you wrote:
    >> >Start building a project and then try and cancel.  The config tool
    >> >doesn't kill make.exe cc1.exe or arm-elf-gcc.exe.
    >> >
    >> >I have some process killing code that I made for windows at
    >> >home if the config tool doesn't have it already. If you want
    >> >it, let me know. You should have the process ID already anyhow
    >> >when the processes are spawned, but for some weird reason the
    >> >config tool might not be able to close the child process. If
    >> >that happens my code should work.
    >> 
    >> Thanks -- there was some child-process code in the original CT
    >> which I should use but I'd also be interested to see your code
    >> in case it's easier to understand :-)

    Jifl> If it's MSDN code we can't use it though....

    Jifl> Also, these are cygwin processes, so they should be killed
    Jifl> in a "cygwin" way so cygwin can do it's own correct cleanup.
    Jifl> Is the new config tool linking with the cygwin dll now? If
    Jifl> so, perhaps using the cygwin kill should be reliable now.
    Jifl> When the original CT came out, cygwin kill was unreliable,
    Jifl> leading to extra complexity in the code.

There have been numerous problems killing cygwin apps from the config
tool and elsewhere over the years. The details depend on which version
of cygwin you are using, and on the exact version of Windows - NT4
and 2000 tend to be better behaved than W98.

Using Windows calls to kill of a cygwin process has proved a bad idea
on occasion: usually it worked fine, but occasionally there would be
some problems in the shared state managed by the cygwin dll and
afterwards other cygwin applications would run into problems. The
exact details were never tracked down. I do not know if current cygwin
is affected.

The "correct" way to kill off cygwin processes is to use the cygwin
kill command, or the equivalent kill() call if the parent process is
linked with cygwin. Going behind cygwin's back is just asking for
trouble. If kill does not work reliably then it indicates a problem in
cygwin and the way it interacts with the underlying OS, and this
problem should be tracked down and fixed. After all, cygwin is open
source. A good first step would be a reproducible test case...

Bart


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]