Currently, there is a plan to make the Java GC perform some cleanup on Tcl_Obj in
TclBlend. Looking at the root cause for the GC trouble, I think there is a problem
with how TclBlend uses Tcl_Obj reference counting. Here is my analysis. I think if
we fix the reference counting, we don't
Resend because the last one didn't have a Subject. Sorry about this. My main SMTP
server went down and I had to use this WEB based email program.
Currently, there is a plan to make the Java GC perform some cleanup on Tcl_Obj in
TclBlend. Looking at the root cause for the GC trouble, I think
I have attached a patch with the rewrite of JavaGetEnv() and
the threads cleanup. I like this approach a lot better
because now there is only one synchronization point,
inside the JavaSetupJava function. I think this will
take care of all of the possible race conditions
during initilization. The
On 8 Aug 2000, Jiang Wu wrote:
There seems to be a bug in the patch.
In the beginning of JavaSetupJava(), it has:
if ((env = JavaInitEnv(env, interp)) == NULL) {
goto error;
}
then at error:
error:
...
On Tue, 08 August 2000, Mo DeJong wrote:
Ok, I fixed that. Besides that, do you like the reorg?
It looks good to me. Let's commit it to the branch.
-- Jiang Wu
[EMAIL PROTECTED]
--
[EMAIL PROTECTED] is brought to you by
the Stanford Alumni
On 8 Aug 2000, Jiang Wu wrote:
On Tue, 08 August 2000, Mo DeJong wrote:
Ok, I fixed that. Besides that, do you like the reorg?
It looks good to me. Let's commit it to the branch.
Done and done.
Mo DeJong
Red Hat Inc
The
OK. Back to the notifier patch. I am not sure if you got my last email on this
subject last night. My mail server wasn't working properly.
When I run your example using:
java::call AppendEventQueueThread queueVwaitEvent [java::getinterp]
update
I get:
numQueued = 9
numProcessed = 9
This
On 8 Aug 2000, Jiang Wu wrote:
OK. Back to the notifier patch. I am not sure if you got my last email on this
subject last night. My mail server wasn't working properly.
When I run your example using:
java::call AppendEventQueueThread queueVwaitEvent [java::getinterp]
update
I
On Tue, 08 August 2000, Mo DeJong wrote:
Nope, I am only seeing 1 event getting processed in that 10 second
delay.
Send me your Notifier.java file. I need to take a look to see if it is different from
what I have.
There is no reason why this should not work. I have been using it for months
Jiang Wu said:
1. In UNIX, TclBlend uses a pipe with non-blocking IO to wake up the Tcl
event loop. If there are multiple event loops in several threads, will
a
single pipe based IO trigger all event loops to wake up?
In the threaded version of Tcl, there are two distinct types of event
Jiang Wu said:
TclBlend does not follow the normal Tcl_Obj reference counting usage.
In Tc
lBlend, a Java TclObject is used as the handle to the underlining
Tcl_Obj:
TclObject
CObject
Tcl_Obj
Both Tcl_Obj and TclObject have reference
On Tue, 08 August 2000, Scott Stanton wrote:
Notes on the Tcl event loop
Thanks for the information. It seems that multi-threaded Tcl already implemented some
cross-platform thread notification, maybe TclBlend should use something like
Tcl_ThreadAlert() to wake up the event loop. But this
On 8 Aug 2000, Jiang Wu wrote:
After spending some hours in gdb tracing the program, it seems that the problem
occurs in tclUnixChan.c:FileInputProc() line 380: *errorCodePtr = errno;
1 byte is written to a non-blocking Tcl file channel. Then 1 byte is successfully
read from the channel.
-Original Message-
From: Mo DeJong [mailto:[EMAIL PROTECTED]]
used is non-threaded, version 8.3.1. Can there be something
bad about using "errno" from multiple threads?
Under Solaris, errno becomes a function that returns a thread
local variable when you compile with
On Tue, 8 Aug 2000, Jiang Wu wrote:
Darn! With problems like this, does it mean that there is no safe way of
using a non-threaded Tcl in a JVM because the JVM is threaded by default.
The JVM is going to allocate one thread to execute non-threaded Tcl code.
Tcl tries to access system
I looked at the Window's version of Tcl. There is no special system level
compiler flag to compile threaded versus non-threaded. So it seems that
non-threaded Tcl on Windows may work fine with Java.
I have to agree that requiring threaded Tcl may be the only option for UNIX.
If non-threaded
16 matches
Mail list logo
