Re: DESTROYing shared objects, finally

[email protected] (Mike Pomraning)
Newsgroups perl.ithreads
Message-ID <[email protected]>
On Thu, 30 Oct 2003, Elizabeth Mattijsen wrote:

> The "inventory" approach is the one that Thread::Pool uses.  But it
> may be simpler than you think:

Seen it; liked it; can't use it.  :-)

IIUC, this prevents an object from being DESTROYed in a thread other than the
one which invoked the constructor (equivalent to storing/checking the value of
threads->tid rather than our unshared, incrementing $cloned).  But this isn't
necessarily the _final_ destruction (and, besides, I might want to get rid of
an object in a thread other than the one which created it).

<digression>
Also, one can sidestep the bookkeeping by returning the object from a thread
join():

  my $orig = new TrackWithThreadPoolTechnique;
  my $copy = threads->new( sub { return $orig; } );
  # $orig and $copy will be DESTROYed in this thread; bummer

</digression>

Suppose my constructor allocates memory in XS and opens a file descriptor.  I
want the object to be useable by threads, but I can't tolerate DESTROYing it
multiple times -- even if I avoid double-free()ing the memory, the object is
ruined prematurely for other threads if I free the mem and close the fd.

(IO::File doesn't have this problem, shared or not.  The underlying fd is
closed only when the last object referring to it vanishes.  However, I think
this is done by maintaining an "fd refcount" table under the hood.)

Never mind non-shared objects for the moment; does it make sense to repeatedly
DESTROY a shared object?  The reason I share $obj is so that this thread's
$obj and that thread's $obj are the same, not copies.  Given that, I expected
the destructor to be called once, and feel like I'm kludging around with
_refcnt() and CLONE.

Would it be sensible to have DESTROY called only once in this case (or
introduce an ANNIHILO method or something)?  IIUC, that'd mean hacking
Perl_sv_clear to be sharedsv-refcount-aware (or swap in an appropriate routine
when threads::shared is used, ala Pl_lockhook).

Regards,
Mike
-- 
Michael J. Pomraning
[email protected]
http://pilcrow.madison.wi.us
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.