01-05-03 18.40, skrev Gurusamy Sarathy p� [EMAIL PROTECTED] f�ljande:
> On Thu, 03 May 2001 13:23:48 +0200, Artur Bergman wrote:
>> The iThread module now works in creating and joining in threads, however the
>> interesting issue is sharing variables between interpreters (otherwise we
>> just have fork...);
>
> Cool. (I'd prefer a name such as threads.pm instead of iThread.pm.)
I was afraid of choosing a name that might collide with what exists today,
but that is easy fixable.
>> The first passing a SV between two threads, if the thread that allocated the
>> SV destructs it will free the arena that the SV used, (assuming
>> perl_destruct_level > 0). I solved this temporarily by creating an empy
>> PerlInterpreter for keeping shared variables in.
>
> We've talked about keeping SV pools that are shared across interpreters.
> I don't know about the viability of this (won't know until implementation
> is attempted, I suspect).
One way around this is just to keep a dummy PerlInterpreter that i just
perl_alloced around for the shared SVs, if it isn't destructed other
interpreters can use SVs defined in it. (or so I think)
>> The second problem is that perl_clone will clone all SVs it can find when
>> cloning. (No big surprise). Which means sharing has to implmeneted by either
>> magic or tie, both have performance problems.
>
> I see no better alternative than magic to implement shared data access.
> Well-written threaded code will not access shared data in the hot
> path, and if it does, the slowdown due to lock contention (blocking)
> should be a much worse hit on performance than the tie overhead will be.
>
> Let's not optimize prematurely!
>> I assume that :shared would have to set a flag on a SV so it is created
>> somewhere off the arena (?) and perl_clone will have to ignore cloning that
>> SV (?).
>
> The way I see :shared working is this:
>
> * :shared declares a normal SV that has a new type of magic
> * the SV is a front-end for access to some shared data (could be a
> region of memory that's created on first access, or could be
> a SV from a global pool)
> * all the magic callbacks for this new magic type will have
> locks to control access (reads don't lock unless a write
> is in progress)
> * shared SVs are cloned just as any normal SV by perl_clone()
Ok, I will try to come up with a prototype use the TIE interface for this.
Artur
