Em Dom, 2010-05-16 às 19:34 +0100, nigelsande...@btconnect.com escreveu:
> 3) The tough-y: Closed-over variables.
> These are tough because it exposes lexicals to sharing, but they are so
> natural to use, it is hard to suggest banning their use in concurrent
> routines.
This is the point I was trying to address, actually. Having *only*
explicitly shared variables makes it very cumbersome to write threaded
code, specially because explicitly shared variables have a lot of
restrictions on what they can be (this is from my experience in Perl 5
and SDL, which was what brought me to the message-passing idea).
> However, interpreters already have to detect closed over variables in
> order to 'lift' them and extend their lifetimes beyond their natural
> scope.
Actually, the interpreter might choose to to implement the closed-up
variables by keeping that entire associated scope when it is still
referenced by another value, i.e.:
{ my $a;
{ my $b = 1;
{ $a = sub { $b++ } } }
this would happen by the having every lexical scope holding a reference
to its outer scope, so when a scope in the middle exits, but some
coderef was returned keeping it as its lexical outer, the entire scope
would be kept.
This means two things:
1) the interpreter doesn't need to detect the closed over variables, so
even string eval'ed access to such variables would work (which is, imho,
a good thing)
2) all the values in that lexical scope are also preserved with the
closure, even if they won't be used (which is a bad thing).
> It doesn't seem it would be any harder to lift them to shared
> variable status, moving them out of the thread-local lexical pads and into
> the same data-space as process globals and explicitly shared data.
It is still possible to do the detection on the moment of the runtime
lookup, tho...
> My currently favoured mechanism for handling shared data, is via
> message-passing, but passing references to the shared data, rather than
> the data itself. This seems to give the reason-ability, compose-ability
> and controlled access of message passing whilst retaining the efficiency
> of direct, shared-state mutability.
That was part of my idea too, I wasn't trying to address remote
processes or anything like that, I was considering doing the queues in
shared memory for its efficiency.
> Only the code that declares the shared
> data, plus any other thread it choses to send a handle to, has any
> knowledge of, and therefore access to the shared state.
If we can overcome the limitations we have in Perl 5 shared values, I'm
entirely in agreement with the above statement (assuming closed-over
values become shared transparently)
> Effectively, allocating a shared entity returns a handle to the underlying
> state, and only the holder of that handle can access it. Such handles
> would be indirect references and only usable from the thread that creates
> them. When a handle is passed as a message to another thread, it is
> transformed into a handle usable by the recipient thread during the
> transfer and the old handle becomes invalid. Attempt to use an old handle
> after it has been sent result in a runtime exception.
This is exactly what I meant by RemoteValue, RemoteInvocation and
InvocationQueue in my original idea.
daniel
