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 need
<>
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
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 o
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:
...
(*env)->ExceptionClear(env);
return TCL_ERROR;
env ca
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:
>...
>(*env)-
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 A
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
T
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 i
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
>
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 month
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 eve
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 c
On Tue, 08 August 2000, Scott Stanton wrote:
>
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 function is not available fo
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 chan
> -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 wit
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 glob
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 Tcl
17 matches
Mail list logo
