Re: Re: Re: Ways and means of killing Win32 processes

[BrowserUk]

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

exec()
Calling exec() within a pseudo-process actually spawns the requested e
+xecutable in a separate process and waits for it to complete before e
+xiting with the same exit status as that process. This means that the
+ process ID reported within the running executable will be different 
+from what the earlier Perl fork() might have returned. Similarly, any
+ process manipulation functions applied to the ID returned by fork() 
+will affect the waiting pseudo-process that called exec(), not the re
+al process it is waiting for after the exec().

Which if I have interpreted it correctly, should mean that you could do something like.

1. Smedge starts wrapper.pl
2. wrapper.pl uses system to start a second copy of the script (in another instance of perl) and passes the process ID of the first to it via the command line. The second copy sits and monitor the presence of the first using some mechanism perhaps kill with an arg of 0 (zero) to check of the first is still in existance or $proc = Win32::Process::Open($orig_pid) to get a handle to the original process and $proc->wait(); to wait for it's demise.
3. The first copy of wrapper.pl then execs the wrapped executable and, if the above description is correct, the original process should then sit and wait until the exec'd executable dies or is otherwise terminated. This would be monitored by the second copy.

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.