> I am not sure this has anything to do with pseudo fork, rather with fork
> semantics. (On unix you will have the same problem if you fork a DBI handler
> for example).
As far as I can understand, under Unix you will be able to use the handle
in parent process, but it will be invalid in the context of child process,
right? So, this is slightly different from what I am talking about:
here (when fork makes threads, not processes), I have access to the handle
from both parent and child processes (should I say threads :) ?), but the
wrapper perl object (like Win32::event or Win32::API in my case) has no way
of knowing that there, magically, has appeared another object, referring to
the same handle... so, any reference counting which is for example used in
Win32::API to determine when to unload the dll is broken -- dll gets
unloaded upon termination of any thread...
In this situation, the CLONED method would allow just to increase the
reference count to the underlying win32 handle by for example calling
"LoadLibrary" once again.
> A simple solution is to rebless the object into another package
What did you mean by that?
> , or do an
> unclean shutdown using POSIX::_exit(0) or kill 9,$$; from the child, thus
> avioiding global destruction of that interpreter.
Yuk! There will be other things that potentially won't get cleaned up.
PS I am relatively new to Perl internals, although have a strong background
in Win32 programming and a limited experience with Unix.
PPS Is there a way (w/out using XS) to globally "override" a builtin perl
function (that is, to override it in each and every module that ever calls
it, without having to modify those modules' sources)?;
* * *
-= Kirill Shpitsa =-
Languages understood: Russian, Ukrainian and English
