in the sense that the kill could create another deadlock.

There is no "deadlock" involved. A process (or thread) that is prevented from running due to unsatisfied blocking IO is simply blocked, not deadlocked.

And, as demonstrated above, you don't need either pseudo-processes or threads in the mix for that to occur. This will never terminate until some hits a key:

perl -e"alarm(10); <STDIN>"
[download]

So, if a pseudo-fork thread is doing some kind of system call (not only IO, but likely, as IO just takes relatively long) we get a deadlock,

First: It doesn't require a system call, any perl op-code that runs for a long time--if I could find one of those pathological regexes, I could demonstrate that--will block interrupts, because since Safe signals were implemented, signals are only seen once the current op-code returns to the run-loop. I'm not sure, but I think that is true of signals on *nix as well as windows rather crappy signals emulation.

But the result isn't a 'deadlock'--which has particular connotations with regard to threading and locking, but can also occur between two (real) processes using IPC. It is just good old fashioned 'blocking'.

There is a risk of a true deadlock if a thread is terminated (ThreadTerminate()), in that the terminated thread could leave a mutex or semaphore in teh locked state thereby preventing further progress by the remaining thread(s) in the process. But again, this isn't attributable to either pseudo-processes or Windows signals emulation.

The same thing can happen whenever you force termination without cleanup--of a thread, pseudo process or real process--that uses any form of locking. Even real processes under *nix using SysV mutexes or even just file locks.