I've been experimenting with integrating tclblend into aolserver, and
after looking at the tclblend code, I'm a little puzzled about
something. In javaCmd.c the variable java declared as type JavaInfo
and currentEnv are declared as global variables, yet I would think
that these two variables
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo The startup stuff is kind of tricky because we need to support
Mo two different kinds of loading. Tcl Blend can be loaded from
Mo Tcl, whick will then load the JVM. Tcl Blend can also be
Mo loaded from a JVM, this means Tcl Blend
After moving back to the u.s., I've started looking into integrating
tclblend into aolserver/nsjava again. Last night I checked out the cvs
sources from the cvs ajuba contract branch, and started to compare it
to version 1.2.6.
I'm curious about the JavaInfo structure in javaCmd.c. When I
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo So it looks like you are right, we need to put the method
Mo cache in thread local storage. The contract branch is clearly
Mo not finished, there is a lot of work that still needs to be
Mo done.
Ok thanks for the sanity check.
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo On Mon, 28 Aug 2000, Daniel Wickstrom wrote:
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Also, when I get tclblend working in aolserver, would you be
interested in incorporating the
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo On Mon, 28 Aug 2000, Daniel Wickstrom wrote:
I would anticipate some changes to the autoconf files and
makefile templates, and the addition of some aolserver specific
'c' files.
Mo That does not sound too bad.
"Jiang" == Jiang Wu [EMAIL PROTECTED] writes:
Jiang I had allocated time to work on this until the end of
Jiang August. Due to various delays, the project was not
Jiang finished in that time frame. I am no longer working on it.
Jiang Looking at the CVS branch, I think the
"Jiang" == Jiang Wu [EMAIL PROTECTED] writes:
Jiang This patch contains my code for the ref count fix. Patch
Jiang is generated against 1.2.6. It passes the test suite
Jiang without any problems. It includes the reflect object bug
Jiang fix, which causes the test suite to
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo Humm, I think so but I can't remember off hand. The problem
Mo with this "fix" is that it currently does not work. There are
Mo strange crashes when running the test suite.
By strange crashes, do you mean that it doesn't consistently
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo That does seem logical. It looks like the Class refs need to
Mo be cleaned up. What do you think of the patch below?
The patch looks good. I'll have to wait until tonight to apply it, as
I can't seem to apply it to the version that I
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo There are two cleanup cases.
Mo TclThreadCleanup is called when a Tcl thread (one that was not
Mo started inside a JVM) is terminated. TclThreadCleanup will
Mo just call DetachCurrentThread() to disconnect the Tcl thread
Mo
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo What do you mean by "The jvm attach is done at the start of
Mo the thread by a registered proc"? Are you not using:
Mo (*javaVM)-AttachCurrentThread()
Mo In JavaInitEnv() to attach the Tcl thread to the JVM? This is
Mo also
"Jiang" == Jiang Wu [EMAIL PROTECTED] writes:
Thanks, this description helps alot.
Jiang Background: The relationship between the various objects
Jiang are quite tricky. It takes some time to think them
Jiang through. Basically, to reference a Tcl_Obj, the C
Jiang structure
"Thomas" == Thomas McKay [EMAIL PROTECTED] writes:
Thomas Can someone send me a pointer to where I can download
Thomas autoconf 2.14. I just checked out tcljava from
Thomas sourceforge and would like to make it. There aren't any
Thomas instructions on doing this so I am
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo Are you up to it? I am going to be working on this object ref
Mo queue thing for some time, so if you could take a whack at the
Mo Notifier it would really help. There is not going to be much
Mo overlap in these changes, so they
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo What version of Tcl are you using? This should not show up
Mo with Tcl 8.3.2 or 8.4. At any rate, it does not matter.
I'm using tcl version 8.3.2.
tclblend/javaTimer.test
javaTimer-3.1 JavaTimerProc
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo On Thu, 26 Oct 2000, Daniel Wickstrom wrote:
Mo It could be related to the event queue, I just don't see it on
Mo my box. A printed stack trace would really help:
Mo replace:
Mo catch {$notifier doOneEvent 0} m
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo I ran the tests again, and it looks like everything is working
Mo just great. I can also run some multi-threaded tests that did
Mo not work in the past.
Mo Are there any remaining issues we need to look at before
Mo merging
I've been investigating the thread cleanup, and it appears that thread
cleanup handlers created with Tcl_CreateThreadExitHandler are only
called when tcl is shutting down. This is true at least for tcl8.3.2.
I haven't looked at tcl8.4.
There is an experimental tcl thread interface in tcl8.3.2
19 matches
Mail list logo
