Peter wrote:
But even at this stage I forsee a problem: How do I make a stream (used
for
internal communication between two java threads) available in the tcl
environment
for Expect to listen on?
It's a shame that this isn't currently possible. I have hacks for Jacl
that allow me to wrap
Will the C based Tcl extensions work the same with the threaded version of
Tcl versus the non-threaded Tcl? One reason for using TclBlend is to access
these extensions such as Expect and Scotty.
I don't really see why we need to require the multi-threaded Tcl. If
TclBlend works with
Well, hopefully one day all of the important extensions
will work properly with threads. For instance, Expect
is not thread-safe, but as long as you only use one thread
with Expect, then it's fine regardless of how Tcl was built.
Jiang and I discussed using checks in the TclBlend code
to do
Re: updated configure.in to get around Tcl package require bug
Thanks Mo. I got the updated, manually re-executed the autoconf so that a new
configure is generated, and got significantly farther smile.
Now, I have some make check problems to ask about. During the make check,
these are the
From: "Scott Redman" [EMAIL PROTECTED]
I haven't read all of your messages, but this looks like the
known error using Solaris and JRE 1.2.2. For some reason
this works on all JREs except 1.2.2 and only on Solaris.
Thanks. I will pursue getting the JRE updated here to 1.3.x .
--
Larry W.
Well, just off the top of my head:
http://www.sunworld.com/sunworldonline/swol-11-1999/swol-11-jacl.html
(Story Server uses Tcl Blend)
http://www.vignette.com/
(Catapult uses Jacl)
http://www.memcad.com/
(HMS uses both Jacl and Tcl Blend)
http://www.hmssoftware.com/
(Embedded Server from Sun
I thought the whole point you were making was that if we require that
Tcl be built with threads then we could remove the JAVA_LOCK stuff.
How do you suggest we implement locking in a non thread enabled version
of Tcl if we are not going to use the current JAVA_LOCK approach?
Mo Dejong
Red Hat
My opinion is that there is no need for any locking for non-threaded version
of Tcl in TclBlend. There is no need for any locking for threaded version
of Tcl in TclBlend.
Here are my reasons:
1. JAVA_LOCK does not serve any useful function, whether Tcl is thread
enabled or not.
2. JAVA_LOCK
Well, how do we prevent the Tcl event queue from being accessed
from multiple Java threads? In the case where Tcl is threaded,
Tcl should do its own locking. In the case where Tcl
is not threaded, I would think we would need the JVM to do
the locking (AKA JAVA_LOCK). I am not convinced that we
Humm, I was under the impression that the Tcl Blend version of
the Notifier was not synchronized and that is why we needed to
protect the notifier. In fact, it is synchronized in "regular Java".
public synchronized void
queueEvent(
TclEvent evt, // The event to put in the
10 matches
Mail list logo
