> 01-06-03 01.22, skrev Jenda Krynicky pRho [EMAIL PROTECTED] f÷ljande:
>
> > There is one more problem with objects that store (or point to)
> > something off Perl symbol table.
>
> Indeed there is, therefore I proposed a CLONE callback on all blessed
> objects when perl_clone is called. I haven't gotten around implmenting it.
There has to be some way to use modules that are not yet updated to
use the callback.
> > Say you use Win32::Semaphore to control the number of subprocesses
> > created at a givven time. You have to create the Win32::Semaphore
> > object in the mother before you start to fork out the children, but
> > the first child to finish destroys the parent's object.
> >
> > The only way to implement this that I found was to
> >
> > bless $sem, "NonexistentPackage"; undef $sem;
> > $sem = Win32::Semaphore->open($name);
> >
> > in the children.
>
> Yes this works, but it is an ugly hack :). I also use kill 9,$$ if I want to
> quit without calling destroy. (there is also POSIX::_exit(0));
I think this is slightly cleaner than suicide.
At least the objects that were created after the fork() are destroyed
properly.
> If an object is implmented in perl it can declare itself shared. Are you
> also gvs can be shared by using the :shared flag. But you want to declare an
> object to become void in the clone. That is rather scary ain't it, it could
> pull out lots of problems for complex structures.
I don't expect this to be the normal way to cope with cloning.
A fallback maybe. It's better to undef the object then to let it
crash everything.
If I get some
Can't call method "Foo" on an undefined value at Foo.pl line ...
I can (usualy) easily find what is not defined. And if the docs say
"Some objects are not cloneable. If so the object will exist only in
the parent thread. Check if there is an updated version of the
module." I know what's going on.
It's far from optimal, but it's better than if one thread ends and
some other stops working with "Invalid handle" or whatever.
> Otoh an object could implment this by nulling its copy when the CLONE
> callback is called. Then it also is up to the object to know if something
> can be shared or not.
If the object knows about the calling, it will probably able to
clone. We have to do something with objects that do not have a clue.
> There is a module called IThread::Safe which implments some unsafe
> perlfunctions (unsafe on non safe c libs) with mutexes around em. You
> suggest we should have a list of all threadsafe/nonthreadsafe perl libraries
> in there? Won't that be maintaince hell for us to update?
>
> Artur
I think that if a module is updated to catch the CLONE callback it
may set some tag.
This way we only have to add modules that are CURRENTLY not safe. And
if a new version comes out and supports cloning it'll set the tag and
voila IThread::Safe (or whoever) will not interfere.
I think the interface could be something like this :
#script.pl
use One::Module;
use Other::Module;
use IThread::Safe::Modules; #
...
__END__
# IThread::Safe::Modules.pm
...
sub import {
...
foreach $mod (keys %INC) { #let's see what did he use
$mod =~ /\.pm$/;
$mod =~ s{/}{::}g;
if ($unsafe{$mod} and ! ${$mod."::__cloneable"}) {
install_default_CLONEr( $mod );
}
}
...
}
__EMD__
Jenda
== [EMAIL PROTECTED] == http://Jenda.Krynicky.cz ==
I wonder why the whole chemistry industry ignores
computer bugs. We all would gladly pay big bucks
for a functional insecticide.
