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.)
>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).
>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()
Implementing shared references is probably the tricky part. It is
also not clear what the semantics of shared references should be:
should only dereference through the shared reference be locked,
or should all use of the underlying data be locked? I think the
latter is the more useful semantic, which means we'll need to check
that shared references are only ever created for shared SVs, and
not regular ones (should be easy to put the check in refto()).
For the first cut, we could probably say shared references are not
supported. ;-)
Note that the global SV pool thing is not a prerequisite for the
above.
Good luck!
Sarathy
[EMAIL PROTECTED]
