Dan Sugalski <[EMAIL PROTECTED]> wrote:At 10:09 PM +0100 12/22/03, Leopold Toetsch wrote:Dan Sugalski <[EMAIL PROTECTED]> wrote:
8) We're probably going to have to rejig the string functions some,
Can you elaborate on that a bit more? Strings are (as any other managed parrot resources) living inside the separated memory pools. Where do you see problems?
Well, consider reallocating a string because it's grown. That requires allocating memory from the interpreter that the string header comes from, which might not be the current interpreter.
I see. A shared PerlString PMC is handled over to a different thread and enlarged in that thread.
Yep. Or an array or hash PMC gets expanded so the backing pool of memory needs reallocation.
> Thatmeans when we reallocate the memory we need to lock the pool the memory came from, and the garbage collector for that interpreter needs to respect the lock as well.
That's the reason, why I came up with the vague idea: shared resources have their own buffer/memory pools. I don't know, if that helps though.
Sort of, but you run into the issue of collecting that space across threads, which can me an issue. You still need to go lock the pool, but now all the threads are going to potentially have a single choke point rather than multiple choke points.
But all this seems to indicate, that shared PMCs need an interpreter back-ptr to reallocate resources. Not only strings got that problem: enlarging shared arrays or hashes also have to use their own header/memory pools.
While its not too complicated to get from an PObj* to the arena its time consuming (more or less, depending on ARENA_DOD_FLAGS), it seems simpler to have an interpreter back-pointer in the (shared) PMC.
Yep, you're right. Let's make it happen. We can use the synchronize pointer and hang a struct off of it with the owning interpreter and the PMC mutex, along with other things we need as we come across them.
> Also, there's the issue of just accessing the string data itself. Ifthe string is from the current interpreter we're safe--there's no way we can be in the middle of a GC run at the same time we access the string's data pointer. That's not the case with strings from a different interpreter--we could be trying to get at the string data while the GC is in the process of moving it around.
Again, not only strings but all kind of containers using managed resources suffer from that problem.
All that seems to imply, that we need two locks for shared access: one for protecting DOD/GC and a second for the PMC. Any container (including PerlStrings) would have to aquire the first (interpreter-global) lock, while a PerlNum only needs the second per PMC mutex. Ugly.
Yeah, it all potentially gets nasty. -- Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
