|Problems? Is your data what you think it is?|
Re: Are Addresses From refaddr Unique Across Threads?by aecooper (Acolyte)
|on Feb 19, 2010 at 20:08 UTC||Need Help??|
Well firstly many thanks for all your responses you have all been most helpful :-).
For brevity I shall refer to the traditional refaddr() on every access the refaddr approach and what I have proposed as the caching approach.
To reply to some of the comments made...
Why Not Use refaddr() Directly On An Empty Hash?
Well in the article that I referenced, someone posted performance results comparing various techniques. When compared against the classic basic blessed hash ref class, the traditional inside-out, refaddr approach ran 37% slower as against the caching variety only running 4% slower. Also using refaddr() every time you want to work out your hash key makes it very sensitive to cloning issues during multi-threading. This requires you to have a CLONE method and the %class_objects hash. Using the caching approach is not affected by the cloning issue and is much simpler and faster. As my class is called 1000s of times a second, performance is an issue.
The data cannot be exposed any more than it can with the traditional refaddr() approach as %class_records is private to the file containing the class (only thing in that file BTW). Anyway the caller could still get the key with the refaddr() approach, its just slightly less obvious.
One Can Compromise Che Object
The only thing that could be compromised is the key. The worst case is that a bit of memory is leaked when someone tinkers around with the internals of the public object. The actual %class_records hash is only accessible from within the class. The refaddr approach does not suffer from this memory leak problem because all they could do to affect the refaddr of the hash is to delete it which will call the destructor.
However accidental corruption is not very likely unlike in languages like C and C++. As for deliberate tinkering they would either quickly loose interest (as it doesn't gain them anything) or change the source code.
Use Of Hashes Containing Fields
Well this is a base class. As for any derived classes they are either going to be basic hash refs (ok could get a field clash but very unlikely as most people doing OO in perl tend to find out about what they are deriving from and are very unlikely to use a field named after the base class), something similar to this one (so will just add another field) or refaddr style ones (wouldn't care). When implementing a base class a blessed reference is the most derivation friendly when compared to code, array and scalar refs.
Basically perfection and complexity vs 98% solution that is a lot faster and simpler...
Why Not Just Use A Counter Or A Random Number?
Hehe yup point taken :-), probably would have done that at some point...
Why Not Upgrade To Perl 5.10?
A lot of distros are still on 5.8 (RedHat, Debian, CentOS, SlackWare?) and I have deliberately developed this software on an oldish distro so that users don't have to go through patching/upgrade hell just to get a library and GUI application working.
Many thanks once again. I will be using a counter/random number approach and check for clashes on object construction.