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
