fix RT#88840, don't terminate a child fork psuedo process in DLL Loader Lock
authorDaniel Dragan <bulk88@hotmail.com>
Tue, 14 Aug 2012 12:50:25 +0000 (13:50 +0100)
committerSteve Hay <steve.m.hay@googlemail.com>
Tue, 14 Aug 2012 12:50:45 +0000 (13:50 +0100)
commitd903973c0527ee5c9f9f559e3e0e3f1aac2ab1cc
treebe07cf40d454e34ee298ba0e6f277220050e19b7
parentbe8851fc38b39ec6167336f4fee669536e99e022
fix RT#88840, don't terminate a child fork psuedo process in DLL Loader Lock

TerminateThread will terminate a thread but leaks all resources
of that thread, and all locks will never be released, as documented in MSDN.
There is no alternative to locks not being released that I see, but atleast
-e "if ($pid=fork){kill(9,$pid)} else {sleep 5}"
in fork.t won't deadlock with this patch since win32_start_child be reached before
TerminateThread happens. The 5 ms timeout can be increased if problems
arise in the future. The HWND of the child is delivered by win32_start_child
very early, before any perl bytecode is executed, therefore the delay is
keeping in spirit with a kill 9. In any case, if the child thread fails
to schedule, (a DllMain in DLL_THREAD_ATTACH of some DLL in the process
deadlocks or does very long (over 5 ms right now) sync IO), the parent interp
will bail out.
win32/win32.c