On Sun, Mar 27, 2005 at 06:31:59PM -0500, Stas Bekman wrote:
> So we have CLONE that allows us to properly clone objects when a new
> thread is started. The current invocation approach really sucks, since
> trying to figure out what things need to be cloned is a pain-in-a-back.
> But it's doable [1]. Previously we have started discussing of passing the
> objects to be cloned as an argument(s) to CLONE, but it didn't get anywhere.
>
> Now I've discovered a new problem. If intentially or accidently you have
> to return an object from a thread callback:
>
> threads->new(\&read_test)->join;
>
> sub read_test {
> my $obj = Foo->new;
> #1;
> }
>
> You're screwed since now you have a dangling temp object which you didn't
> really want to in first place (but can be figured out by reading the
> manpage), but the real problem is that even if you did want it:
>
> my $ret_obj = threads->new(\&read_test)->join;
>
> this object is not properly cloned. If you had a C pointer stashed in
> SvIVX and you have a DESTROY method that frees that pointer, it's a sure
> segfault, since both the parent thread and the child thread will point to
> the same C struct.
>
> So I'd love to see at least perl 5.10 dealing with this properly (of
> course 5.8.x would be lovely too). The wishlist:
>
> 1) have CLONE get the SVs to clone as arguments to it, which will
> tremendously simplify the life of developers.
>
> 2) fix the explained above bug and run the objects through CLONE when they
> are returned from join().
How does this interact with the new CLONE_SKIP thinggy?
--
Spock (or Data) is fired from his high-ranking position for not being able
to understand the most basic nuances of about one in three sentences that
anyone says to him.
-- Things That Never Happen in "Star Trek" #19
