This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
Re: Threads?
Chris Dean wrote:
- Most application code written in Kawa will work fine in a
multi-threaded setup.
To the best of my knowledge.
- 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.
Likewise.
There are a few caveats:
- fluid-let bindings are per thread.
Yes, but (currently, at least) inherited from parent thread.
- If you are managing thread-specific state, you currently may need to
use Futures.
Or fluid-bindings. I believe they work even without Futures. At
least when I took a quick look at the code it looked ok.
- 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?
At least (for now) if you want per-thread default input and output
ports. There may be other cases I can't think of.
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?
Changing an binding (i.e. once you have a Symbol) is probably safe.
Though there may be some state transitions in the type of Constraint
the Symbol uses that may not be safe.
The bigger problem is looking up or creating a binding, e.g. in
Environment.lookup(String). This is not synchronized. These are
called in the class initializers of compiled code. These is a
synchronized statement in require, but my bigger concern is when a
class is initialized because of static reference. I'd have to look
at what is going on and what to do about it. One possibility is
to compile-in synchronization in the class initializers.
Another solution is to not use Symbols for undefined globals. E.g.
a compiler option to require that all identifiers by bound at
compile-time. This would be better for performance.
--
--Per Bothner
per at bothner dot com http://www.bothner.com/per/