01-06-05 17.57, skrev Jenda Krynicky p� [EMAIL PROTECTED] f�ljande:
>> 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.
How? By imposing mutexes around the xsubs?
>>
>> 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.
This will break the normal behaviour people expect from fork(), this problem
is a problem incommon with fork() on external objects in the unix world
(fork with DBI for example can be very bad). I am not sure fixing an
autosemantic for this without fixing it in the fork world would be a good
thing. If you speak about a fix for people using ithreads. How should we do
it? Undef every object that has not declared itself to be safe? The user
must explicitly tell us what objects to null, and then that nulling could be
implmented by a wrapper object or class that listens for the CLONE callback.
>> 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 );
> }
> }
> ...
> }
And what should that default CLONEr be? We cannot clone the C struct behind
it :).
Artur
