[Tcl Java] thread cleanup

2000-10-31 Thread Daniel Wickstrom


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 that allows
a user to control tcl threads from within tcl scripts.  I understand
that this interface will be included in tcl8.4, and threads created
with this interface will call the cleanup handlers created with
Tcl_CreateThreadExitHandler.  So there should be no problem for
threads created within tcl.

This is all well and fine, but the problem is that tclblends design
conflicts with the order of the cleanup handlers.  When a tcl thread
exits, it calls these registered cleanup handlers, and then it
deletes the interpreter for the thread.  The problem in the current
design is that the jvm thread is detached, before the interpreter is
destroyed.  When the intrepter is destroyed it cleans up all of the
remainined Tcl_Obj's which results in a call to FreeTclObject.
FreeTclObject then tries to call the release method for the TclObject
that it represents, and this results in a segfault, because the jvm
has already detached from the current thread.  I came this while
testing in aolserver, and from looking at the tcl source, it appears
that you will have the same problem with the regular version of
tclblend when using the thread interface in tcl8.4.  

Threads created from java will not get segfaults, because the cleanup
routines will not be called.  Of course, you will then have memory
leaks.

-Dan


The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]  
 with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to [EMAIL PROTECTED] 
 with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'. 
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com




[Tcl Java] Re: possible memory.

2000-10-27 Thread Daniel Wickstrom

 "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 this branch back into the HEAD? We can't fix the ref
Mo count problem right now, we need to get this all merged back
Mo into the HEAD and then we can look at overhauling ref
Mo counting, perhaps on another branch.

This sounds promising.  As far as threading changes, there was the
issue of thread cleanup routine not being called.  Other than that
and the ref counting changes that you mentioned, I thinks that's it.
If I get a chance this weekend, I'll spend some time looking at the
thread cleanup issue.

-Dan


The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]  
 with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to [EMAIL PROTECTED] 
 with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'. 
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com




[Tcl Java] autoconf 2.14

2000-10-26 Thread Daniel Wickstrom

 "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 assuming that I: 1)
Thomas autoconf configure.in 2) configure 3) make


You can get autoconf at ftp://ftp.gnu.org, but you shouldn't need it.
The source that you checkout from sourceforge already has a valid
configure script.  You just need to run 1) configure and 2) make.


-Dan


The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]  
 with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to [EMAIL PROTECTED] 
 with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'. 
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com




[Tcl Java] Re: possible memory.

2000-10-26 Thread Daniel Wickstrom

 "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 can be done in parallel.



Ok here is a patch to make the notifier thread safe.  I've run the
test cases on a solaris box, and it still fails with the same test
cases that I posted earlier before I made the modifications.  Let me
know what you think.

How is it going with the object ref queue thing?

-Dan


 notifier-patch.txt


[Tcl Java] Re: ajuba branch

2000-10-26 Thread Daniel Wickstrom

 "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  Contents of test case:
 
 set t [java::new tests.TimerHandlerTest $notifier 100] set
 result [java::field $t value] java::field $t err true lappend
 result [catch {$notifier doOneEvent 0} msg] $msg [java::field
 $t value]
 
  Result was: 0 0 1 0  Result should have been: 0 1
 {java.lang.NullPointerException: TimerHandlerTest} 1 
 javaTimer-3.1 FAILED

Mo Humm, I have not seen this error before either. Could this
Mo have something to do with your Notifier changes?

No these tests were run before I made the notifier changes.  This is a
fresh checkout from cvs.  Since making the notifier changes, I get the
same errors, so the notifier modifications didn't change anything with
regard to the test results.

Mo If not, could you investigate it a bit more? Perhaps get a
Mo stack trace and print it to see where things are going wrong.

I'll see what I can do.  I want to write some tests that will exercise
the enw notifer anyway.

-Dan



The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]  
 with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to [EMAIL PROTECTED] 
 with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'. 
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com




[Tcl Java] Re: ajuba branch

2000-10-26 Thread Daniel Wickstrom

 "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} msg

Mo with:

Mo java::try {$notifier doOneEvent 0} catch {Exception e} {$e
Mo printStackTrace}

Mo If not, could you investigate it a bit more? Perhaps get a
Mo stack trace and print it to see where things are going wrong.
  I'll see what I can do.  I want to write some tests that will
 exercise the enw notifer anyway.

Here is the stacktrace:


% source tclblend/javaTimer.test


 javaTimer-3.1 JavaTimerProc
 Contents of test case:

set t [java::new tests.TimerHandlerTest $notifier 100]
set result [java::field $t value]
java::field $t err true
lappend result [java::try {$notifier doOneEvent 0} catch {Exception e} {$e 
printStackTrace}] $msg  [java::field $t value]

 Result was:
0 1 {unknown java object "java0x1"} 0
 Result should have been:
0 1 {java.lang.NullPointerException: TimerHandlerTest} 1
 javaTimer-3.1 FAILED
% source tclblend/javaTimer.test
java.lang.NullPointerException: TimerHandlerTest
at tcl.lang.TclPkgInvoker.invokeMethod(TclPkgInvoker.java:81)
at tcl.lang.JavaInvoke.call(JavaInvoke.java:254)
at tcl.lang.JavaInvoke.callMethod(JavaInvoke.java:114)
at tcl.lang.ReflectObject.cmdProc(ReflectObject.java:906)
at tcl.lang.Interp.callCommand(Interp.java:983)
at tcl.lang.Interp.eval(Interp.java:791)
at tcl.lang.JavaTryCmd.cmdProc(JavaTryCmd.java:74)
at tcl.lang.Interp.callCommand(Interp.java:983)


 javaTimer-3.1 JavaTimerProc
 Contents of test case:

set t [java::new tests.TimerHandlerTest $notifier 100]
set result [java::field $t value]
java::field $t err true
lappend result [java::try {$notifier doOneEvent 0} catch {Exception e} {$e 
printStackTrace}] $msg  [java::field $t value]

 Result was:
0 {} {unknown java object "java0x1"} 1
 Result should have been:
0 1 {java.lang.NullPointerException: TimerHandlerTest} 1
 javaTimer-3.1 FAILED
% 


The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]  
 with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to [EMAIL PROTECTED] 
 with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'. 
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com




[Tcl Java] thread cleanup - something that works

2000-10-17 Thread Daniel Wickstrom


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 memory, I've had no problems.  

I now suspect that the memory leaking is due to a problem with reference
counting.  I'm currently investigating that issue.

-Dan


The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]  
 with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to [EMAIL PROTECTED] 
 with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'. 
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com




[Tcl Java] Fwd: TclBlend Ref Counting Bug (GC related)

2000-10-13 Thread Daniel Wickstrom

 "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 representing a Tcl object in the C Tcl
Jiang interpreter, TclBlend creates a TclObject, a Java class
Jiang instance using the following relationship:

Jiang TclObject (tcl.lang.TclObject, Java class) contains
Jiang  CObject (tcl.lang.CObject, Java class) contains 
Jianga pointer to Tcl_Obj

In the case above what does the Tcl_Obj represent? Is it just a native
tcl object such as a string, a list, or an array?

Jiang CObject is a subclass of InternalObject
Jiang (tcl.lang.InternalObject).  InternalObject is an abstract
Jiang class containing an interface so that TclObject can be used
Jiang as the common interface to not only Tcl_Obj, but also other
Jiang types of TclBlend objects such as ReflectObject,
Jiang TclInteger, etc, all of those are subclass of
Jiang InternalObject.

Jiang On the C side, the C Tcl interpreter needs access to Java
Jiang objects defined in TclBlend, such as ReflectObject,
Jiang TclInteger, etc.  TclBlend uses a Tcl_Obj implementation to
Jiang wrap around any TclObject using the following relationship:

Jiang Tcl_Obj (A C struct with function pointers to functions
Jiang that are specifically designed to manipulate TclBlend's
Jiang TclObject.  Defined in javaObj.c in TclBlend.)  contains
Jiang reference/pointer to the Java TclObject

This makes sense.  The Tcl_Obj internal rep always holds a jobject
handle to a java TclObject.

Jiang It seems that you can get infinite recusive containment as
Jiang in:

Jiang Tcl_Object contains 
Jiang Tcl_Obj contains 
Jiang  Tcl_Object contains
Jiang  Tcl_Obj contains ...

Yeh this was confusing me, especially when I started thinking about
the changes you made to the refcounting code.

Jiang TclBlend is smart enough to detect such attempt.  When it
Jiang is detected, TclBlend removes the extra level containment
Jiang so that most of the time you will have either:

Is that what's going on in the setInternalRep method of the TclObject
class?  It checks for a CObject internal rep and creates a new
reference to the current TclObject instance if the new rep is not of
type CObject.  Where else is this detection done?

JiangTcl_Object contains Tcl_Obj

Jiang or

JiangTcl_Obj contains Tcl_Object

Jiang The Problem:

Jiang The proposed solution is to never use the GC thread to free
Jiang Tcl_Obj and always use the thread that created the Tcl_Obj
Jiang to free the Tcl_Obj.

My initial impression is that this is the correct way to do it, though
it can be tricky to get all of the reference counting right.

-Dan


The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]  
 with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to [EMAIL PROTECTED] 
 with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'. 
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com




[Tcl Java] Re: leaking memory

2000-10-12 Thread Daniel Wickstrom

 "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 have available right now.

Mo This would tend to happen if you created a lot of Tcl or Java
Mo threads and loaded Tcl Blend into them. Is that what you are
Mo doing? This also sounds like that mem leak problem from
Mo yesterday, do this patch help? The patch is for the
Mo ajuba-tclblend-contract-2000-08-01-branch branch in the CVS.

Exactly.  Each time someone accesses a url a new thread is spawned for
the connection and tlcblend is loaded into it.  In the test case that
I ran, there were probably more than 20 concurrent threads with
tclblend loaded into each of them.

Mo That seems to happen to me too. 

Are you saying that you also don't see the cleanup cache method get called
at the end of a thread?  If not, this would indicate a problem with
the tcl implementation not calling these registered cleanup procs.


Mo It seems like the new cache
Mo cleanup method is getting called when Tcl Blend is loaded into
Mo Tcl, but I am not sure what is going on when you load Tcl
Mo Blend and Tcl into a JVM. How could we test this sort of
Mo thing?

I'm not sure what your saying here, and it's probably because I'm used
to thinking about this stuff in terms of the way it operates in
conjunction with aolserver.  In aolserver there is only one case:

1) Connection thread starts.
2) A new tcl interpreter is allocated to the connection thread.
3) jvm attach to the current connection thread.
4) tclblend is initialized for the current connection thread.
4) run tcl scripts with tclblend calls.
5) thread completes.
6) cleanup thread function is called.  -- this doesn't happen with
aolserver


-Dan


The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]  
 with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to [EMAIL PROTECTED] 
 with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'. 
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com




[Tcl Java] Re: leaking memory

2000-10-12 Thread Daniel Wickstrom

 "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 from the JVM.

Mo JavaCacheCleanup should be called when a Java or Tcl thread is
Mo terminated, its job is to clean up the thread local cache or
Mo classes.

For me these two cases seem to be one in the same.  At the end of a
connection thread, I need to do both JavaCacheCleanup and
DetachCurrentThread. 

Mo I am not sure which of these you are using because the
Mo description below says "Connection thread starts" and then
Mo "jvm attach to the current connection thread", that would make
Mo me think it is a thread created from Tcl.

I think what you're saying is correct.  I've always thought of it as
aolserver starting a connection thread and allocating a tcl
interpreter instance to run in that thread.  The jvm attach is done at
the start of the thread by a registered proc, and after the jvm is
attached to the connection thread, tclblend is initialized.

 1) Connection thread starts.  2) A new tcl interpreter is
 allocated to the connection thread.  3) jvm attach to the
 current connection thread.  4) tclblend is initialized for the
 current connection thread.  4) run tcl scripts with tclblend
 calls.  5) thread completes.  6) cleanup thread function is
 called.  -- this doesn't happen with aolserver

Mo The problem I was seeing is that JavaCacheCleanup was getting
Mo called when I exited Tcl thread but when the JVM exited, I saw
Mo no such callback. This might be because the finalizer was not
Mo called on exit. I need to fix that problem with the Notifier
Mo before I can really test this properly.

I would be happy to see it called at the end of a thread, because I
don't exit the jvm until aolserver is shutdown.

-Dan




The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]  
 with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to [EMAIL PROTECTED] 
 with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'. 
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com




[Tcl Java] Re: leaking memory

2000-10-12 Thread Daniel Wickstrom

 "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 the place where this is called.

Mo Tcl_CreateThreadExitHandler(TclThreadCleanup, NULL);


Mo Perhaps I am just not understanding what you mean. You really
Mo should not need to do your own JVM attach, at least that is
Mo not something I had considered (ugh, we don't really need
Mo another init case).

I should have elaborated.  To use tclblend in aolserver, I basically
had to tear apart javaCmd.c and re-implement it in the structure required
by aolserver.  aolserver provides functions outside of tcl to register
a function at the start of a thread.  I'm using this aolserver
registered function to call AttachCurrentThread.  I'm also calling
Tcl_CreateThreadExitHandler(TclThreadCleanup, NULL) in my init
routine.  Other than javaCmd.c, the rest of the tclblend code is the
same as what I pulled out of cvs.  At some later time, when I
understand everything, I'm going to try and restructure everything to
use the code in javaCmd.c if possible.  If not, I will have one extra
'c' file to support aolserver.

-Dan


The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]  
 with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to [EMAIL PROTECTED] 
 with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'. 
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com




[Tcl Java] Re: merge with aolserver

2000-10-09 Thread Daniel Wickstrom

 "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 "fix" is that it currently does not work. There are
Mo strange crashes when running the test suite. I was thinking
Mo that it might be best to try using one of the other
Mo implementations we talked about (like the free Tcl object
Mo enque thing) in the short term.  After the notifier queue impl
Mo was fixed, things should be working well enough to be merged
Mo back into the HEAD branch. Then, the ref counting stuff could
Mo be worked on in isolation.

If you could send me what you have, I would be willing to look into it
some more.  I've spent a considerable amount of time looking at the
reference counting problem this week-end, and I would like to pursue
it a little further.

-Dan




The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]  
 with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to [EMAIL PROTECTED] 
 with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'. 
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com




[Tcl Java] Re: merge with aolserver

2000-10-09 Thread Daniel Wickstrom

 "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 core dump.  I am
Jiang planning to integrate this into my work product, which is
Jiang using 1.2.6.  But with this fix, it makes life much easier
Jiang to write Tcl commands in Java.

O.k. Thanks.  I'll take a look at these and see if I can apply it to
my work.

-Dan


The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]  
 with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to [EMAIL PROTECTED] 
 with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'. 
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com




[Tcl Java] Re: merge with aolserver

2000-10-09 Thread Daniel Wickstrom

 "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 crash at
the same point in the test suite?

-Dan


The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]  
 with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to [EMAIL PROTECTED] 
 with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'. 
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com




[Tcl Java] Re: merge with aolserver

2000-10-06 Thread Daniel Wickstrom

 "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 following things
Jiang have to be added before you can get a working version:

Has this work been suspended indefinitely?

Jiang 1. The work on fixing how TclObject uses Tcl_Obj's
Jiang reference counting.  

Is this detailed earlier in the mailing list archvies?

 
-Dan


The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]  
 with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to [EMAIL PROTECTED] 
 with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'. 
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com




[Tcl Java] Re: global JavaInfo structure in threaded tclblend.

2000-08-28 Thread Daniel Wickstrom

 "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 changes in tclblend as a
 conditional compile option to support aolserver?  I will try to
 minimize the changes to tclblend as much as possible.

Mo What would you need to change? I can't agree to something
Mo without knowing what it would entail.

I would anticipate some changes to the autoconf files and makefile
templates, and the addition of some aolserver specific 'c' files.

I don't expect a firm commitment from you to add support for aolserver
integration, but I'm interested to know if you are open to the idea.
Your openness to the idea would affect my approach to integrating
tclblend in aolserver.  If however, you don't want the additional
complication to the tclblend distribution, I understand.

-Dan


The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]  
 with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to [EMAIL PROTECTED] 
 with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'. 
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com




[Tcl Java] Re: global JavaInfo structure in threaded tclblend.

2000-08-28 Thread Daniel Wickstrom

 "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. How about a src/aolserver
Mo subdirectory for your .c files?

That works for me.

 I don't expect a firm commitment from you to add support for
 aolserver integration, but I'm interested to know if you are
 open to the idea.  Your openness to the idea would affect my
 approach to integrating tclblend in aolserver.  If however, you
 don't want the additional complication to the tclblend
 distribution, I understand.

Mo Keep in mind that you are going to have to do your own
Mo testing.  If (more like when) I change something that breaks
Mo the AOL build, you are going to have to fix it and send in a
Mo patch.  If you are interested in taking responsibility for the
Mo AOL parts of the code then I am interested in adding the code.

This also works for me.  I would be glad to take responsiblity for the
aolserver-specific code.


-Dan


The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]  
 with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to [EMAIL PROTECTED] 
 with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'. 
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com




[Tcl Java] Re: global JavaInfo structure in threaded tclblend.

2000-08-24 Thread Daniel Wickstrom

 "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.  Could you summarize the changes that
you are going to make to the ajub contract branch?  Is there anything
else that needs to be put into thread-local storage?  It seems that
the notifier code will need to change also.  Is that correct?


-Dan


The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]  
 with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to [EMAIL PROTECTED] 
 with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'. 
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com




[Tcl Java] global JavaInfo structure in threaded tclblend.

2000-08-23 Thread Daniel Wickstrom




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 looked
at this before, I assumed that you would need a seperate JavaInfo
structure per thread.  The code I'm looking at now seems to assume one
global JavaInfo structure that can be used by all tcl threads.  Am I
missing something here, or is this part of the code still work in
progress?  I thought I read somewhere in the java docs that class and
method ids can't be shared between java threads.

-Dan


The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]  
 with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to [EMAIL PROTECTED] 
 with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'. 
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com




[Tcl Java] Threading in tclblend.

2000-06-29 Thread Daniel Wickstrom


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 would be overwritten each time a new thread
starts up.  Am I missing something?  I've noticed using of java locks
throughout the code.  Maybe only one thread can be executing c-code at
any given time?  Any insights would be appreciated.

Dan


The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]  
 with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to [EMAIL PROTECTED] 
 with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'. 
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com




[Tcl Java] Re: [Tcl Java] Threading in tclblend.

2000-06-29 Thread Daniel Wickstrom

 "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 will also need to load
Mo up Tcl.

I can see tclblend being loaded into tcl when you do something like
load tclblend into tclsh, but how do you end up with the reverse case?

Mo In the case where Tcl Blend is loaded into Tcl, the
Mo JavaGetEnv() method is called and this bit of code is
Mo executed.

Mo if (currentEnv != NULL) { return currentEnv; }

O.k. you only init these structures once.  I see that, but what I
don't understand is what happens when another thread comes along and
uses the JNIEnv pointer stored in currentEnv.  My understanding about
this is that for each thread the JNIEnv pointer is different.  My work
on nsjava where I've integrated a jvm to work with aolserver's tcl
interpreters has shown me that this is true.  Also the class, method,
etc., id's stored in the "java" structure need to be different for
each thread.  I think I'm missing something here about the over-all
architecture of tclblend.  Is there only one tcl interpreter thread in
tclblend or are there multiple tcl interpreters?

Mo The tricky part is how Tcl is compiled. If Tcl is compiled
Mo with threads support enabled, then you could use a Tcl mutex
Mo to protect the resources. Problem is, some people might not
Mo want to use the thread enabled version of Tcl.  I am kind of
Mo leaning towards requiring the thread enabled version of Tcl
Mo for Tcl Blend because I think going for a simple solution and
Mo avoiding using JNI when we can is a very good thing.

Just my opinion, but I would require that tcl be compiled with
threads.  It seems that it would make things alot simpler.  Of course
I'm biased, as aolserver will only ever use threaded interpreters :).
What is your current user base like?  Do you think alot of people
have a need for a non-threaded interpreter?  I know the threaded
version is probably slower, but I wonder if it is that significant.

Mo We would certainly welcome any suggestions or insights you
Mo might have on the subject. I hope that we can get all these
Mo threading issues ironed out in the next 3-4 weeks so that we
Mo can cut a 1.3.0 release of Jacl and Tcl Blend for people to
Mo bang on.

As I get into this more, I might have something to offer.  In nsjava,
I attach the jvm to the connection thread, so I have one tcl
interpreter per thread,  I cache the JNIEnv pointer in a cache that is
indexed with the thread id.  The only locking that I do is when I'm
accessing the cache to either put a new env pointer into it or to pull
an env pointer out.  I've run this setup under high-load situations
using apache bench, and I'm not seeing any lock contention.  Basically
I only support one new tcl command called ns_java which is roughly
equivalent to your java::call tcl commmand.  I understand enough about
how aolserver works now, so I could probably extend this to give
nsjava functionality equivalent to tclblend, but I would rather see if
I can merge tclblend into nsjava.  Providing aolserver with the
ability to script java components from tcl would be a very powerful
feature that I think many people would find useful for web based 
development.  I think it would be much better than accessing java
through jsp.

Dan


The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]  
 with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to [EMAIL PROTECTED] 
 with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'. 
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com