Nicholas Clark <[EMAIL PROTECTED]> wrote: > On Thu, Aug 21, 2003 at 03:31:42PM +0200, Leopold Toetsch wrote:
>> When a PMC is shared it is either ro or rw - in all threads. I don't see >> a problem here. > I don't see a problem but I do see a possible optimisation. > I can't remember if you were still in the p5p meeting in Paris when Arthur > explained Sarathy/his idea about doing copy on write of whole scalars in > perl5 for ithreads. A yes that. I wasn't on my first beer at this time but I remember it. I didn't fully understand the implications of this proposal, but with ... [ snip ] > The beauty is that no shared scalar is ever written. > I think that something like this could also work in parrot - you replace the > write vtable ops with the lock/check/copy versions, but leave the read ops > intact. When you do the copy and it's now an unshared PMC you revert the > write vtable ops to the usual fast set. ... this excellent (thanks) explanation, this seems to be very promising and doable, because ... > ... Hence why I made a connection > between split read/write ops and threading. ... a Const$PMC has a different vtable then $PMC. A Shared$Something has the set-like part of its vtable changed, so its yet another PMC type. When there is a need to copy the PMC, because it would be written to, the orginal vtable (being the Const one or not) has to be swapped in, and that's it. So basically, we just have to remember the original vtable* (or class enum) in the changed vtable, to restore the previous one. Then the vtable method gets redone, for the shared case it finally would throw an exception if the PMC was ro (and we could again set the shared vtable here) Albeit, we might end up with a non trivial amount of combinations of vtables consisting of permutations of different vtable pieces ... > Nicholas Clark leo
