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 >
