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. > That > means 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. 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. > Also, there's the issue of just accessing the string data itself. If > the 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. leo
