On Tue, 25 Jul 2000, Mike Schwartz wrote:
> > > I think if it's going to be non-thread safe then the code should sanity
> > > check for thread-crossing calls, perhaps with #ifdef's so performance
> > > concerns can be removed for people who don't want the sanity checks.
> >
> > I like this approach, but the problem is that there is no way to
> > easily turn code on and off automatically (ala #ifdef) in Java.
> > You can use final booleans to get the same behavior, but folks
> > would need to go in and turn these extra checks on, so that
> > > kind of defeats the purpose.
>
> I thought it was the JNI / C code side that wasn't thread safe. You're
> saying it's the Interp pure Java code that's the problem? In that case
> you could define an abstract class with all the Interp interfaces and
> have 2 implementations, one thread safe and one not, and let people
> instantiate whichever they prefer.
> - Mike
I was talking about putting in additional code to check to see if
Interp.eval() was called from a thread other than the one that
created the Interp. This additional code would raise an error
if the user tried to call Interp.eval() from another thread.
You are missing the point of how Tcl interps are synchronized.
Individual calls to Interp methods are not synchronized, and
they are not going to be in the future. This is by design,
it is not a flaw or an option that the user should have.
One of the things the event queue does is provide synchronization
across multiple operations. Say for example you call Interp.eval()
twice:
interp.eval("do 1");
interp.eval("do 2");
If you synchronized on the call to Interp.eval()
then other operations could happen after "do 1" but
before "do 2". That is just not right.
There is also the fact that every call to eval() would be
much slower because a lock would need to be grabbed
before the method could be run (and that means you
would need to put an event into the event queue).
I won't even mention the deadlocks that would
happen if you called Interp.eval() and that called
another method that also called Interp.eval().
See what I mean?
Mo DeJong
Red Hat Inc
----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe: send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
