01-06-06 19.55, skrev Gurusamy Sarathy p� [EMAIL PROTECTED] f�ljande:
> Thanks.
>
> First, some general notes:
>
> * IMHO, we need a two-level cloning approach.
>
> * One level will be purely C code and is meant to give an opportunity
> for XS extensions to duplicate their internal state. If the
> extension exports a C routine (not XS) called clone_Foo (akin to
> bootstrap_Foo) that function will be called by perl_clone()
> with two arguments: the new interpreter that is being created,
> and the "private data" of that extension. This also needs some
> conventions/support established in xsubpp to declare the "private data"
> in an .xs file so that the boiler-plate code can all be generated
> by xsubpp (like it generates boot_Foo, basically). Note that by
> "private data", I mean C data that is normally declared static
> in non-threads code. Some conventions already exist for such data;
> see Storable and DBI for examples and to extract out the common
> boiler-plate.
>
> * The second level is support for a CLONE() callback at the perl
> level. This needs another perl_clone() option, since the fork()
> emulation does not need this (or it has the wrong semantics),
> while the Thread extension might.
If we call CLONE on all stashes then we will catch all XS modules that
define a CLONE. Won't that be enough for supporting C level code?
I don't see a different need for C level or Perl level objects which can
represent outside data that needs to be cloned. Then people can use TLS,
PL_modglobal or store data in whatever way they desire. Forcing people to do
it the way Storable right now does it seems wrong, while the CLONE apprach
lets people do it that way.
>From the discussion on the perl-ithreads list there has been trouble with
DBD::ODBC for example which thus needs support for a CLONE callback.
> You only seem to be addressing the second level here. More comments on
> that below.
>
> On Wed, 06 Jun 2001 18:17:22 +0200, Artur Bergman wrote:
>> This is a patch that calls CLONE on all blessed objects that support it
>> during a perl_clone.
>>
>> The reason we need to collect the objects is because the enviroment is not
>> setup correctly during sv_dup!
>
> Are you perchance calling it in the context of the half-created
> interpreter? That will certainly not work. Use PERL_SET_CONTEXT()
> to temporarily switch the context to the parent interpreter before
> making the call.
>
> That said, queuing up and calling them at the very end of perl_clone()
> seems like the right approach.
As we want to call the CLONE from the new interpreters perspective we better
be in it, I also think this is the correct approach.
>> If somone would like to point me where to look to extend this support to
>> call it on classes and not only object I will happily extend it.
>
> I don't think calling it for all objects is the right design due to
> performance considerations. Calling it once for each stash should be
> sufficient. If a particular package wants to implement it for all
> objects it creates, it can do so itself.
Ok, as we now have weakrefs I agree. Will rework patch.
>> + if (SvOBJECT(dstr)) {
>> + av_push(PL_clone_callbacks,dstr);
>> + }
>> +
>> +
>> return dstr;
>> }
>>
>> @@ -8969,6 +8974,7 @@
>> while (i-- > 0) {
>> PL_origargv[i] = SAVEPV(proto_perl->Iorigargv[i]);
>> }
>> + PL_clone_callbacks = newAV(); /* Setup array of objects to callback
>> on */
>
> Does this *need* be kept in the interpreter structure? I suspect it
> should be a non-arena AV, or a simple malloced SV** array instead that
> is used purely within perl_clone() and functions called by it.
>
>
> Sarathy
> [EMAIL PROTECTED]
>
I did that to avoid having to pass the array around in all the sv_dups and
friends. I could keep it in a TLS if that is better.
Artur
