Mo DeJong wrote:
> I think this one is along the same lines. The finalizer thread seems
> to be called decrRefCount() which is calling FreeTclObject(). I
> think we need a more general solution to the problem of the
> finalizer thread walking into an interp at some random time.
My understanding of 1.1 finalizers is that calling anything that can
allocate objects as a side effect is a very bad idea, since finalizers
are often invoked in the first place because memory is exhausted.
Also synchronization or anything that can cause the finalizer thread to
block should be avoided if possible.
> Can we create a queue of objects that have been finalized?
> We could then clear this queue in a Tcl "after idle" call.
Possibly. The concurrency is a little tricky to solve... you never know
when finalization will be called or from what thread. It might be
doable with `volatile' variables, but unfortunately volatile is not yet
implemented in Sun's VM... that's a long story in its own right.
> Should be make the gc thread block until a given Tcl event
> has finished? This would need to be done by adding an event
> to the Tcl event queue and then letting the GC thread go
> when Tcl was ready to process the event.
Blocking a finalizer on 1.1 could be fatal... see above.
Finalizers are evil, period. These are times I wish the Tcl core had
garbage collection... not that I wish to start that thread (again)...
but if it did, the finalizers could go away.
--
Jeff Sturm
[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 [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
