develooper Front page | perl.perl5.porters | Postings from November 2003

Re: dealing with objects cloning under ithreads

Thread Previous | Thread Next
Mike Pomraning
November 15, 2003 16:12
Re: dealing with objects cloning under ithreads
Message ID:
On Sat, 15 Nov 2003, Elizabeth Mattijsen wrote:

> I guess the question is: can  threads::shared::_refcnt be considered
> part of the threads API?

I hope it lingers until shared objects are DESTROYed only once; that'd solve a
lot of problems in a very natural way.  :-)

(I expect an unshared object to be multiply DESTROYed -- it's copied, after
all.  When I share an object, however, I'm putting forth one single thing for
everybody to play with, and would like it to suffer destruction only once.)

> In any case, the problem is specific for unshared object really.

Well, specifically for objects unshared from Perl's perspective but with an
underlying shared resource or operation (a socket shutdown, XS-alloc'd
memory, etc.).

Flipping on share() unfortunately doesn't take care of the problem, but it
does allow manual _refcount-checking/destruction as a workaround.

> Objects from modules that don't expect to have multiple DESTROY's
> called on their objects

Perl filehandles are interesting in this context -- they behave like I'd
expect a shared object to behave.  If I open($fh, ...) and undef($fh) in a
different thread, the underlying fd sticks around until the last $fh
reference evaporates.

I believe this is b/c Perl essentially does CLONE/fd bookkeeping under the
hood for file-ish things -- one approach suggested in this thread for the
general problem.  Not as natural, IMHO, as expecting a single object to be
destroyed once.

Apologies -- I know that patches are preferred to plaintive posts, but my own
attempts (a shoehorned a PL_dtorhook/shared.xs gambit) haven't been pretty.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About