V
C Tcl_List internal rep (F)
If this were the case, then there would be no memory loss.
-- Jiang Wu
[EMAIL PROTECTED]
The TclJava mailing list is sponsored by Scrip
the interp, goes back into the thread pool. The thread itself is never
deleted, only the resources used by the thread.
TclBlend allows a Tcl program to use Java. It also needs to work the other
direction, which is allowing a Java program to use Tcl.
-- Jiang Wu
[EMAIL PROTECTED
$a1
$a1 toString
java::call tcl.lang.TclList append $interp $a1 $a1
$a1 toString
I get a stack overflow after the last command.
SymcJIT Panic: Unhandled stack overflow in native code...cannot recover.
Addr:
10037e63
-- Jiang Wu
[EMAIL PROTECTED
some Tcl work
4. Delete the Tcl interpreter
5. Delete the thread
6.
-- Jiang Wu
[EMAIL PROTECTED]
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
cleaned up by the garbage
collector.
But we have decided that it is a bad idea to clean up Tcl_Obj inside the
garbage collector. So we remove those code. As a result, Tcl_Obj (1) is
not cleaned up by anyone.
-- Jiang Wu
[EMAIL PROTECTED]
> -Original Message-
> From: Daniel Wickstrom [m
eases to zero. Then later,
the ReflectObject attempts to use the pointer to the free'ed Tcl_Obj (2), which can
cause a segmentation fault.
There may be other places in TclJava, where the above type of thing happen.
-- Jiang Wu
[EMAIL PROTECTED]
e the GC thread to free Tcl_Obj and always use the
thread that created the Tcl_Obj to free the Tcl_Obj.
See below for more analysis of the problem. You can search the maling list archive
for more discussion on this under the general subject of "GC".
-- Jiang Wu
[EMAIL PROTECTED]
-
I ran your test on my version of the fix. I don't see any crash. One
difference in my code is that I didn't remove any of the reference counting
code that was in the C part of TclBlend. I.e. when a Tcl_Obj is created to
wrap a TclObject, it adds a ref count. Theoretically, this is not needed
s
. But
with this fix, it makes life much easier to write Tcl commands in Java.
-- Jiang Wu
[EMAIL PROTECTED]
> -Original Message-
> From: Daniel Wickstrom [mailto:[EMAIL PROTECTED]]
> Sent: Monday, October 09, 2000 6:51 AM
> To: [EMAIL PROTECTED]
> Subject: [Tcl Java]
ation code in
/win/winNotifier.c and /unix/unixNotifier.c
-- Jiang Wu
[EMAIL PROTECTED]
On Thu, 05 October 2000, Dan Wickstrom wrote:
>
> I recently merged the code from the ajuba-contract branch with
> nsjava/aolserver and it seems to be work pretty well on linux.
> Operation on so
In TclBlend 1.2.6, when a ReflectObject is created to represent a TclObject,
the ReflectObject does not preserve() the TclObject. But the ReflectObject
holds on to the TclObject for a long duration in its hash table. When the
TclObject is dereferenced, it can cause the ReflectObject to contain a
xputil does not properly handle Windows environment variables. It interprets the "\"
path separator and ";" that is to distinguish multiple paths in Windows environment as
Tcl significant.
Here is the patch:
Index: xputils.tcl
==
feature, a bug, or a limitation?
-- Jiang Wu
[EMAIL PROTECTED]
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the sub
the right solution, but I suppose it
is the cheapest solution and takes the heat off the people who already
contributed a lot to the product. Maybe a company can provide binary
distribution service and charge $99 per copy to cover the cost of the
testing, follow the commercial Linux model.
-- Jia
The point I was making is that having everyone compiling
Tcl/TclBlend/extensions is big waste of time. Ideally, people can download
and use so that they can focus on developing solutions using the tools
rather than worrying about compiling the tools. But I guess that is as much
a
and vendor
variations. Not having pre-compiled versions do not solve the real problem.
It only pushes the problem to the user. That may be the only solution, but
it is very good in my mind.
-- Jiang Wu
[EMAIL PROTECTED]
The T
using -D_REENTRANT (but without
-DTCL_THREADS) to compile a non-threaded Tcl. The Solaris problem did go
away using this special Tcl compilation.
-- Jiang Wu
[EMAIL PROTECTED]
The TclJava mailing list is sponsored by S
eaded Tcl can interact badly with Java, so can these Tcl
extensions that are not thread enabled. If that is the case, even if we can
make Tcl work with the JVM, there is no guarantee that the extensions can
work.
-- Jiang Wu
[EMAIL PROTECTED]
> From: Mo DeJong <[EMAIL PROTECTED]>
>
em globals. JVM also tries to access the same
system globals.
-- Jiang Wu
[EMAIL PROTECTED]
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with the
y used is non-threaded, version 8.3.1. Can there be something bad about using
"errno" from multiple threads?
Another strange thing if I run the same Java program on a smaller example, then it
seems to work OK. When the error does happen, there are many threads in the process.
-- Jiang Wu
it for months with all
sort of asynchronous Tcl scripts without any problems.
-- Jiang Wu
[EMAIL PROTECTED]
--
[EMAIL PROTECTED] is brought to you by
the Stanford Alumni Association and Critica
This is the desired result because the thread sleeps 1 second, then posts an event,
then repeats. The vwait event waits for 10 seconds. So the thread can post a maximum
of 9 events during this 10 seconds.
Is this what you get also?
-- Jiang Wu
[EMAIL PROT
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 Stanfor
env can be NULL.
-- Jiang Wu
[EMAIL PROTECTED]
--
[EMAIL PROTECTED] is brought to you by
the Stanford Alumni Association and Critical Path.
The TclJava mailing list is sponsored
the reference count
is not decremented to 0
6. do not pass Tcl_Obj to other threads, this is not supported by Tcl anyway
With this fix, I dont' think there is a need to make the GC free Tcl_Obj.
-- Jiang Wu
[EMAIL PROTECTED]
--
[EMAIL PROTECTED
ce count
is not decremented to 0
6. do not pass Tcl_Obj to other threads, this is not supported by Tcl anyway
With this fix, I dont' think there is a need to make the GC free Tcl_Obj.
-- Jiang Wu
[EMAIL PROTECTED]
--
[EMAIL PROTECTED] is b
about "reading only
1 byte at a time to avoid some race condition".
Your insights into these matter are greatly appreciated.
-- Jiang Wu
[EMAIL PROTECTED]
> From: Scott Stanton <[EMAIL PROTECTED]>
> Date: Mon, 07 Aug 2000 11:07:26 -0700
> To: Jiang Wu <[EMAIL
event loop to execute. The C version Tcl
shell does not run the event loop by default.
Take another example, in a tclsh, if you do:
% after 1000 {puts hello}
What should happen after 1 second?
-- Jiang Wu
[EMAIL PROTECTED]
cessed [java::field $AQT numProcessed]
# Kill this other thread.
java::field $AQT killed 1
puts $numQueued
puts $numProcessed
# I get 9 for numQueued and 9 for numProcessed
-- Jiang Wu
[EMAIL PROTECTED]
--
[EMAIL PROTECTED] is brought to you
the exact commands used to produce the problem?
% source <... the Tcl script part of your source code ...>
% set x 1
% after 2 {set x 2}
% vwait x
-- Jiang Wu
[EMAIL PROTECTED]
--
[EMAIL PROTECTED] is brought to you by
the Stanford Alumni
right thing to do.
> This is all getting a little wacky, perhaps we need to split
> JavaGetEnv up into JavaGetEnv and JavaInitEnv, that might
> make things more clear.
Sounds reasonable.
-- Jiang Wu
[EMAIL PROTECTED]
--
[EMAIL PROTE
On Sun, 06 August 2000, Mo DeJong wrote:
> If I do 2 vwaits, then a single event is
> processed from the event loop, but that seems to be all.
How did you do 2 vwaits?
-- Jiang Wu
[EMAIL PROTECTED]
--
[EMAIL PROTECTED] is brought to you b
be placed around 1, 2, and 3 in TclBlend_Init.
Synchronization should be placed around 3 in Interp_init.
After initialization, only 2 is used. 2 does not require synchronization after
initialization.
-- Jiang Wu
[EMAIL PROTECTED]
---
ince I don't have an UNIX machine to test this, I am sending this patch
separately.
-- Jiang Wu
[EMAIL PROTECTED]
Index: Makefile.in
===
RCS file: /cvsroot/tcljava/Makefile.in,v
retrieving revision 1.14
diff -u -r1.14 Ma
.
I outlined the various initialization paths the TclBlend can go through and
how the mutex protects these situations in the following document, item 3
and 4. Your comments and questions are welcome.
http://www-cs-students.stanford.edu/~jwu/blendchanges.txt
-- Jiang Wu
[EMAIL PROTEC
I don't see the PATH to your Tcl dll.
Open a DOS prompt, then type:
dumpbin -imports C:/Program Files/Tcl/lib/tclblend/tclblend.dll
For each dependent dll, make sure that you can find it on your path.
-- Jiang Wu
[EMAIL PROTECTED]
> -Original Message-
> From:
s created. The thread
continues on doing other work without using the event queue of 'interp'.
How do we get this thread to free objects on the "free list"?
-- Jiang Wu
[EMAIL PROTECTED]
The TclJava
he thread sends the script to a separate
slave Tcl interpreter process. Then the thread can kill the slave process
if the process does not respond in a pre-determined amount of time.
Let user be able to run scripts in the "untrusted" mode for debugging.
Later, runs the same scripts
Jiang Wu
[EMAIL PROTECTED]
> -Original Message-
> From: Mike Schwartz [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, July 26, 2000 10:56 AM
> To: Jiang Wu
> Cc: Mo DeJong; [EMAIL PROTECTED]
> Subject: RE: tcl Blend and Java threads...
>
>
> Here's
It should work. What is the JVM environment you are using? Is it 1.2,
native thread?
-- Jiang Wu
[EMAIL PROTECTED]
> -Original Message-
> From: Mike Schwartz [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 25, 2000 9:52 PM
> To: Jiang Wu; Mo DeJong
> Cc: [
gramming is to design functional areas that are thread
safe.
Tcl + Tcl/Blend is thread-safe as a functional area even though most of its
methods are not thread safe.
-- Jiang Wu
[EMAIL PROTECTED]
The TclJava mailing list is sp
returns the Interp.
-- Jiang Wu
[EMAIL PROTECTED]
> -Original Message-
> From: Mike Schwartz [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 25, 2000 3:58 PM
> To: Mo DeJong
> Cc: [EMAIL PROTECTED]
> Subject: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] problem invoking
>
Oops. I am sorry about my earlier email. I didn't realize the email
program was using the html formatting for the reply. I will be more careful
from now on.
-- Jiang Wu
[EMAIL PROTECTED]
> -Original Message-
> From: Mo DeJong [mailto:[EMAIL PROTECTED]]
> Sent: Tu
. There are a number
variation on this scheme depending on how you implement the
notifier.
Of
course, the problem is that the above is not part of TclBlend. If you are
short on time, then you may need to find a different
solution.
--
Jiang Wu
[EMAIL PROTECTED]
-Original Message
ing for Java thread B to finish in
the JVM. The code deadlocks.
When sharing a long running piece of code, other forms of synchronization
work better such as locks and message passing. Tcl provides message passing
as the way to communicate between Tcl interpreter threads.
-- Jiang Wu
[EMA
of the original
Reflect objects. Original post is attached below.
-- Jiang Wu
[EMAIL PROTECTED]
-Original Message-
From: Jiang Wu
Sent: Friday, June 23, 2000 4:18 PM
To: 'Mo DeJong'; Jiang Wu
Cc: [EMAIL PROTECTED]
Subject: RE: [Tcl Java] A Tcl or TclBlend problem?
> ---
yte compiler works. That
may explain why people don't see this in Jacl or when run the command
interactively.
-- Jiang Wu
[EMAIL PROTECTED]
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send
e executed inside Tcl, not TclBlend. There is no control over
what representation is picked by Tcl. This is the cause for the whole mess
with the "command not found" we have been discussing lately.
-- Jiang Wu
[EMAIL PROTECTED]
-
me cases. Is there a way to create a reflect
object and lock it as an atomic operation in Tcl?
set x [java::new -lock String foo]
Otherwise, it may not work.
set x [java::new String foo]
java::lock $x <-- may or may not work
-- Jiang Wu
[EMAIL
uot; should have destructor.
> A file handle in Tcl is just a hash table mapping from the
> string name to the file descriptor.
A "reflect object" in Tcl is just a hash table mapping from
the string name to the "Java object".
The difference is that f
nsideration. I use Tcl and TclBlend with
extensions that are C based. These extensions that are not designed or
tested under a multi-threaded environment. I have a higher confidence level
in using the non-threaded Tcl with these exten
p that could not be disposed of.
Well, there are things like file handles, which are locked down.
set x [file open foo]
fileevent $x readable "read $x"
unset x
will not remove the file handle.
-- Jiang Wu
[EMAIL PROTECTED]
---
e argument is retrieved from the Tcl's procedure stack,
which is just a string only representation of what I passed in.
I had to write my workaround using a string<->object mapping scheme like the
ones used in ReflectObject, but without the reference counting.
-- Jiang Wu
[EMAIL PROTECTE
error you encountered?
-- Jiang Wu
[EMAIL PROTECTED]
> -Original Message-
> From: Dr Wes Munsil [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 28, 2000 12:16 AM
> To: Jiang Wu
> Cc: [EMAIL PROTECTED]
> Subject: [Tcl Java] Re: [Tcl Java] A Tcl or TclBlend problem?
tered this error in my use of TclBlend. One of my earlier
email demonstrates this behavior:
-Original Message-
From: Jiang Wu [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 23, 2000 10:28 AM
To: [EMAIL PROTECTED]
Subject: [Tcl Java] A Tcl or TclBlend problem?
This problem may be related t
There are also problems with the returned TclObject from "getVar", "setVar",
"getResult" of the Interp class. Those TclObjects usually contains CObject
as the internal rep. But TclList is by far the most difficult to deal with.
-- Jiang Wu
[EMAIL PROTE
ide a
TclObject. TclString can be safely GC'ed because it has no link to any Tcl
C data structures.
-- Jiang Wu
[EMAIL PROTECTED]
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to
> -Original Message-
> From: Jeff Sturm [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 26, 2000 10:23 PM
> To: Jiang Wu
> Cc: [EMAIL PROTECTED]
> Subject: [Tcl Java] Re: [Tcl Java] preserve/release or use GC
>
> Jiang Wu wrote:
> > TclObje
((Long) oldFreeTclObjPtrs.elementAt(i)).longValue());
}
}
} // end of CObject
Any comments?
-- Jiang Wu
[EMAIL PROTECTED]
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL
> -Original Message-
> From: Mo DeJong [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 23, 2000 3:15 PM
> To: Jiang Wu
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Tcl Java] A Tcl or TclBlend problem?
>
> You mentioned that doing an after with a list object solved
&g
ter address as its string representation. Then, given the
string representation, a valid C object can be found.
-- Jiang Wu
[EMAIL PROTECTED]
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [E
that it leaks C Tcl_Obj. I think this can
be solved without rewriting the whole ref count stuff.
-- Jiang Wu
[EMAIL PROTECTED]
> -Original Message-
> From: Mo DeJong [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 21, 2000 7:58 PM
> To: Dr Wes Munsil
> Cc: [EMAIL PROTECT
ect's ref count when setting the next result, the Tcl object won't be
free'ed until the Java CObject decides to free the object also.
-- Jiang Wu
[EMAIL PROTECTED]
The TclJava mailing list is sponsored by Scriptics
> -Original Message-
> From: Mo DeJong [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 19, 2000 12:05 PM
> To: Jiang Wu
> Cc: Dr Wes Munsil; [EMAIL PROTECTED]
> Subject: RE: [Tcl Java] Re: [Tcl Java] another deadlock
>
> On Mon, 19 Jun 2000, Jiang Wu wrote:
d
"TclObject.release()". Then, when the Java GC is invoked to clean up the
associated Java object, the GC need not access any Tcl stuff. Though, I am
not sure about automatically creating a list of objects to be finalized.
-- Jiang Wu
[EMAIL PROTECTED]
> -Original Message-
above problems need to be fixed in order for TclBlend to pass most of
the Tcl regression tests.
-- Jiang Wu
[EMAIL PROTECTED]
-Original Message-
From: Mo DeJong [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 15, 2000 6:45 AM
To: [EMAIL PROTECTED]
Subject: [Tcl Java] New patch for loa
MonitorEnter and MonitorExit from the
TclBlend code should not do any harm.
-- Jiang Wu
[EMAIL PROTECTED]
-Original Message-
From: Dr Wes Munsil [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 13, 2000 9:50 PM
To: [EMAIL PROTECTED]
Subject: [Tcl Java] what I now know about the deadlock
2
I am not sure about how well JDK 1.1.8 work with TclBlend. I have not
tested TclBlend with JDK 1.1.8. Are you unable to upgrade to JDK 1.2?
-- Jiang Wu
[EMAIL PROTECTED]
-Original Message-
From: Dr Wes Munsil [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 13, 2000 11:31 AM
To
TclBlend uses whatever the C based Tcl has. There is a history command in
Tcl. You should use a separate thread to run the Tcl interpreter. If you
don't, you may run into crashes and deadlocks.
-- Jiang Wu
[EMAIL PROTECTED]
-Original Message-
From: Zhumei Wang [mailto:[
nes that sets the java environment unchanged
because TclBlend depends on that.
-- Jiang Wu
[EMAIL PROTECTED]
-Original Message-
From: Dr Wes Munsil [mailto:[EMAIL PROTECTED]]
Sent: Sunday, June 04, 2000 9:46 PM
To: Scott Redman
Cc: [EMAIL PROTECTED]
Subject: [Tcl Java] Re: [Tcl Java] final
Here is the patch with the description of the problems solved in the patch.
Without the patch, my Java program causes an access violation when loading
TclBlend.
-- Jiang Wu
[EMAIL PROTECTED]
-Original Message-
From: Jiang Wu [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 04, 2000 3
e are some potential threading problems. You also need to patch the
existing TclBlend. You may want to take a look at:
http://www-cs-students.stanford.edu/~jwu/Using_Tcl_in_Java.html
which discuss how to embed Tcl in Java.
-- Jiang Wu
[EMAIL PROTECTED]
-Original Message-
F
JAVA_LOCK (See javaNotifier.c, line 133). So I don't
think the purpose of JAVA_LOCK is to protect the Tcl event queue.
This brings up a big question: can the notifier of a non-thread enabled Tcl
interpreter be safely alerted by multiple threads.
-- Jiang Wu
[EMAIL PROTECTED]
-Or
how do we
protect the non-threaded Tcl interpreter from being accessed by multiple
Java threads?" My answer to that is "use the interpreter's event queue",
just like you would when using thread enabled Tcl.
-- Jiang Wu
[EMAIL PROTECTED]
-Original Message-
From: Mo DeJong [
en I will be
OK with requiring threaded Tcl with TclBlend.
-- Jiang Wu
[EMAIL PROTECTED]
-Original Message-
From: Mo DeJong [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 17, 2000 2:25 PM
To: Scott Redman
Cc: Jiang Wu; [EMAIL PROTECTED]
Subject: [Tcl Java] Re: [Tcl Java] RE: [Tcl Java] R
underlining Tcl is thread-enabled or not. This way, there won't
be any access to the Tcl interp from any thread other than the "owner"
thread. Then there is no need for JAVA_LOCK at all, even for the
non-threaded Tcl.
What do you think?
-- Jiang Wu
[EMAIL PROTECTED]
-Original
is the same as the inner class method, minus the:
interp.getNotifier().queueEvent(...);
and getNotifier().sync();
For non-blocking call, use "wrappedInterp.asyncExecuteCommand(...)".
-- Jiang Wu
[EMAIL PROTECTED]
-Original Message-
From: Mo
uot;problem 1" because I don't have a clear idea on why
the global "JAVA_LOCK" mutex was used. My feeling is that the global mutex
is not needed. Is it possible for someone at Scriptics to dig up the
original design doc to figure out purpose of the "JAVA_LOCK"?
-- Ji
Are you starting a standard Tcl shell first, then load TclBlend? Are you
embedding the Tcl interpreter into a C program that is not the "tclsh.exe"?
How are you using multi-threads in your program?
-- Jiang Wu
[EMAIL PROTECTED]
-Original Message-
From: Sendur Sellakum
Oops. Never mind my email. I replied to the wrong message. I meant to
send my question to a different person. Sorry about that.
-- Jiang Wu
[EMAIL PROTECTED]
-Original Message-
From: Suvarna Ayyagari [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 12, 2000 11:24 AM
To: [EMAIL
.
-- Jiang Wu
[EMAIL PROTECTED]
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
Are you starting a standard Tcl shell first, then load TclBlend? Are you
embedding the Tcl interpreter into a C program that is not the "tclsh.exe"?
How are you using multi-threads in your program?
-- Jiang Wu
[EMAIL PROTECTED]
-Original Message-
From: Suvarna Ayyaga
you have more than one thread,
use the event queue.
You can also implement the Shell with the file argument using the event loop
method by using 2 threads. One runs the event queue, and the other sends
"source ", then sends "exit" to the event queue.
-- Jiang Wu
[EMAIL PROTE
I just noticed that there are some "^M" characters in the patch file. I
hope it is OK. Let me know if those characters causes any problems for you.
-- Jiang Wu
[EMAIL PROTECTED]
> -Original Message-
> From: Jiang Wu
> Sent: Wednesday, April 05, 2000 2:28
.
Apply the patch to:
Shell.java
ConsoleEvent.java
in the Jacl source distribution.
-- Jiang Wu
[EMAIL PROTECTED]
<>
jaclshell.patch
w to apply the patch and run the
shell.
-- Jiang Wu
[EMAIL PROTECTED]
<> <> <>
<>
ConsoleEvent.java
Shell.java
blendshell.patch
README.blendshell
allows one to write a Java based shell using native TCL through TclBlend. I
will post my modified Jacl shell later this week that you can use to try out
the patch.
-- Jiang Wu
[EMAIL PROTECTED]
==
TR#4352
;t do anything
other than supporting the Shell in TclBlend. What do people think? Any
preferences?
-- Jiang Wu
[EMAIL PROTECTED]
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send
to do
"Interp.evalFile()".
Having TclBlend 1.3 require Tcl 8.3 will simplify matters.
-- Jiang Wu
[EMAIL PROTECTED]
-Original Message-
From: Mo DeJong [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 23, 2000 2:54 PM
To: Jiang Wu
Cc: [EMAIL PROTECTED]
Subject: RE: [Tcl Java] Re: [Tcl Java
at still want vfork
can add -Dfork=vfork to the compile flags. [Bug: 942 2228 1312]
So to use Tcl 8.2.3 with JDK 1.2.2, we need to patch the unix/tclUnixPipe.c
to use "fork" instead of "vfork". After making this fix, everything worked
as expected.
-- Jiang Wu
child process
// signal handler reverted to SIG_DFL in the parent process
Losing the signal handler causes the process to core dump later on when
accessing certain Java code.
-- Jiang Wu
[EMAIL PROTECTED]
The TclJava mail
directories
or files. Can there possibly be a conflict in signal handling between TCL
and the JVM?
-- Jiang Wu
[EMAIL PROTECTED]
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL
}
Of course, having this extra class is not absolute necessary. It is only a
convenience.
-- Jiang Wu
[EMAIL PROTECTED]
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAI
d() without blocking. Otherwise, in
TclBlend, the calls to Tcl_CommandComplete will need to be in a TclEvent.
What do you think? Is Tcl_CommandComplete() thread safe? I couldn't find
anything indicating one way or the other.
-- Jiang Wu
[EMAIL PROTECTED]
-Original Message-
From: M
of tcl.lang.Interp. I was not sure if
Jacl did that by design.
-- Jiang Wu
[EMAIL PROTECTED]
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with
t
3. return the result back to the caller of
TclInterp.completeCommand().
TclInterp will be implemented such that any thread can call its method.
-- Jiang Wu
[EMAIL PROTECTED]
-Original Message-
From: Ian F. Graham [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 16, 2000 1:47 AM
may look into fixing this issue. Using multiple interpreters in my server
may be beneficial.
-- Jiang Wu
[EMAIL PROTECTED]
-Original Message-
From: Mo DeJong [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 02, 2000 3:41 PM
To: [EMAIL PROTECTED]
Subject: [Tcl Java] Re: [Tcl Java] Usi
y other Java thread trying to access any of the tcl.lang.* native
method will block due to the global monitor. Is this intended?
Thanks for your help.
-- Jiang Wu
[EMAIL PROTECTED]
BTW, the good news is that if I compile TclBlend without the synchronization
calls, my test Java program is able to
98 matches
Mail list logo