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
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
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
On Tue, 25 Jul 2000, Mike Schwartz wrote:
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
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
, and returns the Interp.
-- Jiang Wu
[EMAIL PROTECTED]
-Original Message-
From: Mike Schwartz [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 25, 2000 3:58 PM
To: Mo DeJong
Cc: [EMAIL PROTECTED]
Subject: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] problem invoking
tclBlend calls from within
-Original Message-
From: Mike Schwartz [mailto:[EMAIL PROTECTED]]
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
