Well, this is a matter of personal taste I suppose, but in my view
making non-threadsafe code in this day-and-age, especially code that is
intended to interoperate with a language (Java) that is designed to
make it easy to build threaded apps, is problematic. Asking
programmers to build event queues to avoid the problem seems like not a
great solution, because (a) it represents a language non-orthogonality
gotcha, and (b) it makes it more work for programmers to accomplish
what they want.
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.
But, I already mentioned the sanity check idea, and I don't mean to belabor
the point...
Thanks for all your work on tclBlend
- Mike
> Date: Tue, 25 Jul 2000 15:31:39 -0700 (PDT)
> From: Mo DeJong <[EMAIL PROTECTED]>
> To: Mike Schwartz <[EMAIL PROTECTED]>
> cc: [EMAIL PROTECTED]
> Subject: Re: [Tcl Java] Re: [Tcl Java] problem invoking tclBlend calls
from within Java threads
>
>
> On Tue, 25 Jul 2000, Mike Schwartz wrote:
>
>
> > Hmm, I just realized that the issue is the Interp.eval code isn't thread
> > safe, so it just needs to run in a single Java thread (not necessarily the
> > Java main thread). So the code I suggested below won't work but you
get the
> > idea -- have the code sanity check the call and not silently allow someone
> > to stumble on a known limitation in the code...
> >
> > thanks
> > - Mike
>
>
> It is not a "known limitation". The fact that most of the methods
> in the interp class are not thread safe is by design. The thread
> safe event queue is the way to go. I am open to suggestions as to
> how we could help people to not make this mistake in the future.
> I think better documentation is the best approach, but writing docs
> is boring so folks do not seem to want to help with that.
>
>
> 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