Dave Mitchell wrote:
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?
Do you think it makes any difference? The bug is about the returned object
not being cloned. This cloning must be done, no matter whether it's
CLONE'd or CLONE_SKIP'ped
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
