On Fri, Oct 15, 2010 at 11:04:18AM +0100, Tim Bunce wrote:
> 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.
I was recently reminded of the ongoing formal specification of Web Workers,
which fits that description quite well:
http://www.whatwg.org/specs/web-workers/current-work/
Since no one seems to have mentioned it in the thread I thought I would.
>From the intro:
This specification defines an API for running scripts in the background
independently of any user interface scripts.
This allows for long-running scripts that are not interrupted by scripts
that respond to clicks or other user interactions, and allows long tasks
to be executed without yielding to keep the page responsive.
Workers (as these background scripts are called herein) are relatively
heavy-weight, and are not intended to be used in large numbers. For
example, it would be inappropriate to launch one worker for each pixel
of a four megapixel image. The examples below show some appropriate uses
of workers.
Generally, workers are expected to be long-lived, have a high start-up
performance cost, and a high per-instance memory cost.
Tim.
> 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.
>
