On Tue, 24 Oct 2000, Jiang Wu wrote:
> That may be true for your specific case. Though, it is not true in general.
> One could also potentially delete the interpreter without removing the
> thread. For example, one may be using a pool of Java threads to do some
> work. One thread is retrieved, creates a Tcl interp, do some work, delete
> 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]
Yeah, that is a nasty one. We really need to create a good document
that details all of these create/destroy cases.
In this case, the thread would hold the same notifier but
the interp it was create in would be different. I am not
sure if this would blow things up. It might be enough
to put a call to System.gc() in the Interp destroy
callback. Not only do we need to doc this, but we
need regression tests for these edge cases too. I
have been thinking about how to include thread
tests in the existing regression test suite, I
think a --with-thread option that points to
where the Thread extension is build is the
only way to go.
Mo DeJong
Red Hat Inc
----------------------------------------------------------------
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
