Em Ter, 2010-05-11 às 21:45 -0300, Daniel Ruoso escreveu: > he threading model topic still needs lots of thinking, so I decided to > try out some ideas.
After I sent the second version, I just realized I could make it simpler by just assuming "one OS thread per Coroutine Group"... so here goes the new version. 0 - No memory is shared between threads, so no locking is necessary. 1 - A value and a coroutine always belong to a thread, thus naturally implementing synchronized access to data. 2 - Coroutines are, conceptually, the equivalent to green threads, running in the same OS thread. Coroutines waiting for a return value are "blocked". 3 - The interpreter implements a scheduler, which will pick one of the "waiting" coroutines, it may also suspend a coroutine in order to implement time-sharing. 4 - In order to implement inter-thread communication, there are: 4.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 it. 4.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 thread to execute that invocation. 4.3 - An "InvocationQueue" is a special type of "MessageQueue" that accepts only "RemoteInvocation" objects. 4.4 - A "RemoteValue" is an object that proxies requests to another coroutine group through a "RemoteInvocation". 5 - The thread group boundary is drawn by language constructs such as async, the feed operator, junctions, hyper operators. 6 - A value might have its ownership transferred to another thread 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 "RemoteInvocation"s. 7 - 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 thread. 8 - 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". 9 - Exception handling gets a bit hairy, since exceptions might only be raised at the calling scope when the value is consumed. 10 - List assignment and Sink context might result in synchronized behavior. daniel