Dan Sugalski <[EMAIL PROTECTED]> wrote:
I get 1) - 7) and it totally matches my thoughts :)
8) We're probably going to have to rejig the string functions some, and access them via a vtable off strings or something of the sort, so we can swap in and out threadsafe memory allocation and string allocation routines.
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. 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. Otherwise we can end up with multiple allocations from the same pool without synchronization, or the GC yanking the contents around without synchronization, both of which are very bad.
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.
> 9) We need to add a share() entry to the vtable list for PMCs.
To swap in the LOCK-protected vtable variant or to morph() SELF into a shared reference?
Yes. Either way will work.
> Type 1) Start a new thread with a new interpreter that shares*nothing* with the original, not even any communication.
faking fork() for Win32?
Fork's more a full COW'd type two thing, as it gets a copy of the environment. It's often useful to have a pool of semi-independent or completely independent interpreter threads in an embedded context. A multiuser online game, for example, might want a number of independent threads for different players, a web plugin might want a separate independent thread for each instance of the plugin on a page, or someone may be doing something I've not thought of.
> There'll be more, and soon, but let's hack into this part to startwith and we'll go from here.
Actually, let's please address things as they arrive. The big picture is very reasonable and of ocurse necessary. OTOH there are many small design issues involved - I did address 2 of these recently - I'd be really glad, if you could have a look at these too ;)
I'll dig into 'em. Part of the reason I wanted to hold off a bit was that I didn't want to be in the situation of getting some of the details done right and then have to throw them out because the assumptions they were based on got invalidated. :)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
