Em Ter, 2010-05-11 às 21:45 -0300, Daniel Ruoso escreveu:
> The threading model topic still needs lots of thinking, so I decided to
> try out some ideas.
After BrowserUK feedback and some more reading (including
http://www.c2.com/cgi/wiki?MessagePassingConcurrency ) and links from
there on, I decided to rewrite that ideas in a bit different model, but
still with the same spirit.
0 - The idea is inspired by Erlang and the IO Language. Additionally
to OS threads there are the "Coroutine Groups".
1 - No memory is shared between "Coroutine Groups", so no locking is
2 - A value and a coroutine always belong to a "Coroutine Group",
which should be assigned to a single OS thread, thus naturally
implementing synchronized access to data.
3 - The interpreter implements a scheduler, which will pick one of the
"waiting" coroutines that belong to the groups assined to the
current thread. The scheduler may also suspend a coroutine in
order to implement time-sharing. The scheduler should support
"blocking" states in the coroutines.
4 - When comparing to Perl 5, each coroutine is an ithread, but memory
is shared between all the coroutines in the same group, given that
they will always run in the same OS thread.
5 - When a coroutine group is created, it is assigned to one OS
thread, the interpreter might decide to create new OS threads as
necessary, it might optionally implement one OS thread per
6 - In order to implement inter-coroutine-group communication, there
6.1 - A "MessageQueue" works just like an Unix Pipe, it looks like
a slurpy array. It has a configurable buffer size and
coroutines might block when trying to read and/or write to
6.2 - A "RemoteInvocation" is an object that has a identifier, a
capture (which might, optionally, point to a "MessageQueue"
as input) and another "MessageQueue" to be used as output.
New coroutines are created in the target group to execute
6.3 - An "InvocationQueue" is a special type of "MessageQueue"
that accepts only "RemoteInvocation" objects.
6.4 - A "RemoteValue" is an object that proxies requests to
another coroutine group through a "RemoteInvocation".
7 - The coroutine group boundary is drawn by language constructs such
as async, the feed operator, junctions, hyper operators.
8 - A value might have its ownership transferred to another group if
it can be detected that this value is in use only for that
invocation or return value, in order to reduce the amount of
9 - A value might do a special "ThreadSafe" role if it is thread-safe
(such as implementing bindings to thread-safe native libraries) In
which case it is sent as-is to a different group.
10 - A value might do a special "ThreadCloneable" role if it should be
cloned instead of being proxied through a "RemoteValue" when sent
in a "RemoteInvocation".
11 - The "MessageQueue" notifies the scheduler whenever new data is
available in that queue so the target coroutine might be raised.
12 - Exception handling gets a bit hairy, since exceptions might only
be raised at the calling scope when the value is consumed.
13 - List assignment and Sink context might result in synchronized
comments are appreciated...