On Wed, 9 Aug 2000, Scott Stanton wrote:
Mo DeJong said:
It sure would make life easier if we just required Tcl
threads to use Tcl Blend. The notifier thing would go
away because we could count on threads being there.
I'm all in favor of this. As the threaded version of Tcl becomes
-Original Message-
From: Mo DeJong [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 09, 2000 1:34 PM
To: [EMAIL PROTECTED]
Subject: [Tcl Java] Re: TclBlend Initialization Mutex
Con:
Non-thread safe extensions may have problems under Unix.
It seems that there are at least two
On Wed, 9 Aug 2000, Jiang Wu wrote:
-Original Message-
From: Mo DeJong [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 09, 2000 1:34 PM
To: [EMAIL PROTECTED]
Subject: [Tcl Java] Re: TclBlend Initialization Mutex
Con:
Non-thread safe extensions may have problems under
-Original Message-
From: Mo DeJong [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 09, 2000 4:14 PM
To: [EMAIL PROTECTED]
Subject: [Tcl Java] Re: TclBlend Initialization Mutex
Having to keep two separate versions of Tcl around is just
not convenient.
I am open to any
-Original Message-
From: Mo DeJong [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 09, 2000 5:14 PM
To: [EMAIL PROTECTED]
Subject: [Tcl Java] Re: TclBlend Initialization Mutex
Yes, they may be fixed in the future. Though I can't stop
working waiting
for them to be fixed
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
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
21:15:22 -0700 (PDT)
To: [EMAIL PROTECTED]
Subject: [Tcl Java] Re: TclBlend Initialization Mutex
Resent-From: [EMAIL PROTECTED]
Resent-Date: Tue, 8 Aug 2000 21:15:52 -0700 (PDT)
On Tue, 8 Aug 2000, Jiang Wu wrote:
Darn! With problems like this, does it mean that there is no safe way
Yes, you are correct. I noticed this after doing more research into the
notifier and event loop implementation in Tcl.
Per thread event loop can be achieve in Java easily. But there are some
outstanding questions:
1. In UNIX, TclBlend uses a pipe with non-blocking IO to wake up the Tcl
event
12 matches
Mail list logo
