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 queue.
You are right in saying that the JVM should be protecting the event queue.
Currently, TclBlend performs this protection by not letting any Java thread
posting any event to the native Tcl's event queue.
Java Thread 1 Java Thread 2... Java Thread N
||
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 nee
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 doe
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 Inc
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
On Thu, 18 May 2000, Larry W. Virden wrote:
> 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 .
Looks like you are running JDK 1.2 from Sun.
On Thu, 18 May 2000, Peter wrote:
> Hi,
>
> I've been using Tcl/Tk heavily for several yers, java to some extent,
> and I'm
Sounds like an interesting combination. I would love to read a paper
about this project when you are finished.
> currently investigating Expect for testing purposes. Sinc
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
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.
-- Scott
> -Original Message-
> From: Larry W. Virden [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 18, 2000
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 .
Now, I have some make check problems to ask about. During the make check,
these are the only warn
Hi. I maintain a Tcl software catalog on the internet at
http://www.purl.org/NET/Tcl-FAQ/>. One of the things I would
like to know is whether any of you have written tools, extensions, articles,
books, web pages, etc. which make use of TclBlend and/or Jacl.
If so, I would surely appreciate a po
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 some
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 multi-threa
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 wr
Hi,
I've been using Tcl/Tk heavily for several yers, java to some extent,
and I'm
currently investigating Expect for testing purposes. Since we will be
interfacing a bunch of simulators (separate Unix processes) and real
targets (dedicated hardware) from
the same test system as we also want to te
16 matches
Mail list logo
