|Problems? Is your data what you think it is?|
Re: Re: Re: Ways and means of killing Win32 processesby BrowserUk (Pope)
|on Feb 03, 2003 at 06:44 UTC||Need Help??|
I did think that you might be able to get around this problem by forking the wrapper process into two and then have the parent process exec the wrapped executable. The thought was that the exec'd executable would run under the original process id, and the child process would know that id and so, be able to monitor it. Smedge would kill the parent and leave the child alone to do its clean-up job.
Unfortunately this doesn't work (under AS anyway). Firstly the exec'd process runs under a new pid not that of the process it replaces. Secondly, the pseudo nature of forked processes under AS, means that when the exec occurs the parent dies, and it takes the child process (thread in reality) with it.
Reading perlfork I came across this
Which if I have interpreted it correctly, should mean that you could do something like.
Not a 'nice' mechanism, but it might work.
The reason for my doubt of the veracity of the above statement from perlfork is that I was unable, in a quick test, to verify it. However, I have come to trust the docs and doubt myself in these situations until I have proven (or had proved) otherwise.
Examine what is said, not who speaks.
The 7th Rule of perl club is -- pearl clubs are easily damaged. Use a diamond club instead.