On Thu, Oct 14, 2010 at 11:52:00PM -0400, Benjamin Goldberg wrote: > > From: tim.bu...@pobox.com > > > > So I'd like to use this sub-thread to try to identify when lessons we > > can learn from ithreads. My initial thoughts are: > > > > - Don't clone a live interpreter. > > Start a new thread with a fresh interpreter. > > > > - Don't try to share mutable data or data structures. > > Use message passing and serialization. > > If the starting subroutine for a thread is reentrant, then no message > passing is needed, > and the only serialization that might be needed is for the initial > arguments and for the > return values (which will be gotten by the main thread via join). > As for starting a new thread in a fresh interpreter, I think that it might > be necessary to > populate that fresh interpreter with (copies of) data which is reachable > from the > subroutine that the thread calls... reachability can probably be > identified by using > the same technique the garbage collector uses. This would provide an > effect similar to > ithreads, but only copying what's really needed. > To minimize copying, we would only treat things as reachable when we have > to -- for > example, if there's no eval-string used a given sub, then the sub only > "reaches" those > scopes (lexical and global) which it actually uses, not every scope that > it could use.
Starting an empty interpreter, connected to the parent by some 'channels', is simple to understand, implement and test. In contrast, I suspect the kind of partial-cloning you describe above would be complex, hard to implement, hard to test, and fragile to use. It is, for example, more complex than ithreads, so the long history of ithreads bugs should server as a warning. I'd rather err on the side of simplicity. Tim.
