Huh,
Huh
Huh
I think I will find this is not really a threads bug, will look at it.
Arthur
On söndag, juli 21, 2002, at 08:22 , Elizabeth Mattijsen wrote:
This may be of interest to module authors who are looking at making
their modules thread-safe. This is particularly important if your
module has a DESTROY subroutine that actually does something, such as
DBI drivers.
Because of a bug in 5.8.0, the DESTROY method will be called too many
times when you have created threads in a threaded environment. The
extra times (by the looks, once for each thread created + once for the
main thread) it _is_ called, the first parameter to DESTROY is
defective (by the looks of it, pointing to some random item).
Please note that this problem only exists when threads have actually
been created. It does not seem to occur when you are just executing
your program in a Perl built with thread-support, but without actually
starting any threads. But since any module can start a thread without
it being visible to the outside world, it _is_ something to be aware of
nonetheless.
You should therefore _always_ check the validity of the first value
passed to DESTROY and make sure it is what you expect it to be. If you
don't, you're looking at indeterminate (strange) execution errors or
segfaults.
The check could be as simple as:
return if ref($_[0]) ne 'your::class::name';
Please note that you cannot use the isa() method, as you may not be
dealing with an object anymore at this stage. So this makes it tough
for sub-classes. So maybe:
return unless ref($_[0]);
could be enough, but as value passed to DESTROY seems to be random, it
_could_ conceivably be pointing to another (valid) object.
Hope this will save some people some time as it cost me most of today
to figure this one out... ;-(
Liz
