This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
Re: Threads?
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/