Re: Threads?

[Chris Dean <ctdean at mercedsystems dot com>]

Thanks!  Let me try and figure out the bottom line:

- Most application code written in Kawa will work fine in a
  multi-threaded setup.
- Most application code will have the same restrictions that Java code
  has.  For example, you must synchronize around critical areas in the
  same way you would in Java.

There are a few caveats:

- fluid-let bindings are per thread.
- If you are managing thread-specific state, you currently may need to
  use Futures.
- Changing bindings in a top level Environment is not thread safe.

Is that right?  If so, a couple questions: When do you have to use
future?  What can happen if a change a binding in a top level
Environment?  Can it corrupt that one binding or can the entire
Environment become corrupted?

Regards,
Chris Dean

Per Bothner <per at bothner dot com> wrote:
> Chris Dean wrote:
> > I'm a little confused about the state of multi-thread support in Kawa.
> > The fluid-let docs say: "The temporary bindings are only visible in
> > the
> 
> > current thread, and its descendent threads".  And the Threads docs say:
> > "So far, little or no effort has been made into making Kawa thread-safe.
> > There are no per-thread bindings, and the current input and output parts
> > are global.  That needs to change".
> > Those sound contradictory to me.  Is the Threads doc still correct?
> 
> No.  fluid-let bindings are per-thread.  They get inherited
> by child threads.  (There is a related discussion of "parameters"
> at http://srfi.schemers.org/srfi-39/ when whether threads should
> inherit binding state.  That may effect fluid-let.)
> 
> The current input and output ports are not global.  They are
> per-Future.  Note than parts of the Kawa design require you to use
> Futures to manage thread-specific state.  This design pre-dates
> the newer per-thread CallContext, and perhaps should be re-done.
> 
> Creating and modifying Bindings in Environments is probably
> not thread-safe, and this may be a problem.  Note that
> undefined identifiers may involve creating Bindings at
> class loading time.  I'll have to think about how to fix this.
> (Anyway, I'm not satisfied with how Environments work, and
> how they relate to "namespaces" and "packages".)
> -- 
> 	--Per Bothner
> per at bothner dot com   http://www.bothner.com/per/