Dan Sugalski <[EMAIL PROTECTED]> wrote:Okay, now that we're getting more into extensions and NCI access, we need to add an extra array to the root set of the interpreter.
... (A PMC may be in the registry multiple times, and if so each unregister removes *one* reference)
It's fine for this to be a simple array for now. I realize that means O(n) access times,
I'd use a custom hash with the PMC address being the key[1]. /Me thinks, it doesn't help, when a PMC gets registered multiple times - its always the same address - removing it multiple times is fine, the first succeeds, following fail silently, they do nothing.
Well, that's the thing. We need to match register and unregister calls. If a library registers a PMC twice that PMC should live at least until it's unregistered twice. Yeah, it's a recursive mutex sort of thing and arguably the extension code shouldn't do that, but... better safe than sorry. I think I'd rather leak PMCs than crash and die because a PMC was DOD'd too soon.
The hash wins, when about 4 or 5 PMCs are in the array - IIRC.
Cool. I really don't care, it just has to work. :)
[1] pmc_freeze.c has one of these
Q: Is there any chance, that these PMCs get shared, leak out from one into another interpreter/thread?
Oh, definitely. Arguably a PMC that's shared should be on the registry of the sharing interpreter until all other threads that reference it die, but I'm not sure that'll end up happening. It has some issues that need addressing.
Oh (and not to you, Leo, specifically) it's probably time to start thinking about a mark-and-sweep garbage collector. While I *really* like copying collectors, they make thread access a lot more problematic. I can see swapping in a M&S collector for the current copying collector if threads are enabled.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
