Mon 05 Jan 2009 09:54:43 AM UTC, comment #8:
Thanks!
I've looked at the patch and it looks correct but does seem rather complicated but I believe I understand the dilemma.
We want to avoid adding extra checks (like CLS_ISINITIALIZED which would have to be adapted anyways) the hot path.
We are constrained in the class structure layout due to binary compatibility (or we would add a preliminary dtable there to avoid the external linked list, and have message dispatch also check there under the recursive lock on the cold path).
But I'm wondering if we could use the dtable of the meta class during initialization as a fallback for the cold path under the mutex... i.e.:
if
a) the classes dtable is not set yet
b) the dtable of the meta class is set
assume we are currently initializing so lets take the mutex to insure we are thread that's initializing (double checking once we have the lock to see if some other thread was just finishing up)
If we got the lock and the dtable of the meta class is still set, we can assume this is the thread sending a message lookup during +initialize. We use the meta classes dtable for message lookup to finish processing +initialize.
I still need to verify that the dtable of the meta class isn't used for anything else. I'm also haven't convinced myself that this can't produce a deadlock yet. But it would be great if we could avoid the linked list and all the extra helper functions.
I was hoping to come up with a proof-of-concept during the holidays but that didn't work out so I decided to post the idea for now.
|