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 wou
> "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 Tc
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
>>>>> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
Mo> On Wed, 23 Aug 2000, Daniel Wickstrom wrote:
>> I'm curious about the JavaInfo structure in javaCmd.c. When I
>> looked at this before, I assumed that you would need a seper
>>>>> "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 w
>>>>> "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
>
> "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 thin
> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
Jiang> 1. The work on fixing how TclObject uses Tcl_Obj's
Jiang> reference counting.
>> Is this detailed earlier in the mailing list archvies?
Mo> Humm, I think so but I can't remember off hand. The problem
Mo> with this "
> "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 su
> "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 con
Last weekend I ran the merged tclblend/aolserver combination using
apache-bench to make concurrent accesses of multiple urls, and I
noticed that the memory size was growing over time. I think this is
probably due in part to the java info cache not being cleaned up. It
seems that at the end of
> "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 t
> "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 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
> "Jiang" == Jiang Wu <[EMAIL PROTECTED]> writes:
Jiang> I ran your test on my version of the fix. I don't see any
Jiang> crash. One difference in my code is that I didn't remove
Jiang> any of the reference counting code that was in the C part
Jiang> of TclBlend. I.e. when
> "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> s
I was never able to get Tcl_CreateThreadExitHandler to work for either
the TclThreadCleanup or the JavaCacheCleanup routines. As a
work-around I decided to call both of these cleanup routines at the
end of the JavaInterpDeleted function. I've run this setup under
load, and other than leaking me
> "Dan" == Dan Wickstrom <[EMAIL PROTECTED]> writes:
Dan> It appears that the splitList method is only called from
Dan> within the setListFromAny method The setListFromAny method is
Dan> then used in most of the TclList methods. It's not clear to
Dan> me why the TclList obj
> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
>>
>> I'm running with the following:
>>
>> redhat 6.2 tcl8.3.2 tcljava from souceforge ajuba contract
>> branch blackdown jdk1.1.8_v1
Mo> That really should work, everything you are using is the same
Mo> as my ins
> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
Mo> I just got a fresh CVS checkout from SF and ran the tests with
Mo> IBM JDK 1.3 (on Linux) and it worked just fine. I don't know
Mo> what to tell ya. You are using the branch tag:
Mo> ajuba-tclblend-contract-2000-08-01-branc
> "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
> "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,
> "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 JavaTimer
>>>>> "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> repl
> "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>
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 th
27 matches
Mail list logo