I wrote:
Maybe you could do something insane and heroic, like keep a
registry of pointer addresses that represent qualified objects.
Something like what David Golden does with Class::InsideOut to
provide thread safety. Add each object to the registry when it is
created, delete it when it's DESTROYed. It would require a lot of
code, but I'll bet it would be faster than sv_derived_from. How
desperate are you?
Now you've got me thinking, Jeremy.
Right now, KinoSearch isn't thread-safe. However, if I make it so, a
web-spidering app could have separate fetcher threads dealing with
individual http requests and not getting hung up on slow servers.
That's a killer feature... so I'm desperate enough to try something
difficult.
There's no way for me to make all the C-struct based classes in
KinoSearch thread safe without a registry. Some of them have mutex
locking requirements -- you don't want two indexers modifying the
same index at the same time, for instance.
I'm thinking that there ought to be one giant registry structure, a
private variable that springs into being when "use KinoSearch;" is
invoked, that registers ALL KinoSearch related objects across all
threads. What form should this data structure take? A linked list?
A hashtable? Thinking out loud...
typedef struct registration {
SV **ref;
U32 class_id;
SV* (*clone)(SV*);
void (*deregister)(SV*);
struct registration *next;
} Registration;
KinoSearch is designed to use as few objects as possible, so I think
the overhead of creating this registry might be workable --
especially if all the calls to sv_derived_from can be eliminated.
Marvin Humphrey
Rectangular Research
http://www.rectangular.com/
