Using fork on win32 for anything other than simple uses just creates problems. On win32, fork is emulated using a thread, and exec spawns a new process running the exec'd program and the thread waits for that child process. The 'pid' you get back is a funny (negated) thread id, not a process id.

You are given no access to the process id of the spawned process, and as there is (could not be) any parent-child relationship between the thread that is spawned and the process it monitors, killing the thread via is funny thread-id doesn't kill the process.

Upshot. Using fork on win32 is fraught with problems. If you need to do it, using the forking open which returns the real pid of the forked process is usually preferrable. However, even that has problems. Unless you take care to ensure that Perl doesn't decide to run the program you asked for via a shell, you can end up with the pid of the shell rather than the program you asked to run and again, you have no access to the pid of the actual process and cannot kill it.

Historically, unlike POSIX platforms, all win32 processes were considered peers. Ie. There was no parent-child relationship between a process B start by a process A. Killing process A left process B untouched. There are now, and have been for many years, options to CreateProcess that create a hierarchal relationship between processes such that killing process A above would also terminate process B, (see the "End process tree" option on the Task Manager context menu), but Perl has never caught up in this regard.

If, as implied by your post, you are mixing threads with fork, you are in a world of hurt.