On Mon, 19 Jun 2000, Jiang Wu wrote:
Would the GC problem still exist if the underlining Tcl is thread enabled?
In other words, is it OK to call "FreeTclObject()" from any thread in the
thread enabled Tcl?
It may not be a good idea to block the GC thread. For this scheme to work,
one
On Mon, 19 Jun 2000, Jeff Sturm wrote:
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
Mo DeJong wrote:
I am not sure what volatile has to do with anything. I was under the
impression those were for serialization.
Volatiles are potentially useful because loads/stores are guaranteed to
occur in order (if the VM is implemented correctly). There are certain
idioms based on
Mo DeJong wrote:
What is a "thin lock"? Did you mean spin lock? I don't see what is
wrong with a good old mutex, but putting one in means we would
need to require a thread safe version of Tcl. I don't really
like the "use the JVM to do locking" hacks in there now. Using
the JVM to do locking
On Mon, 19 Jun 2000, Jeff Sturm wrote:
Mo DeJong wrote:
What is a "thin lock"? Did you mean spin lock? I don't see what is
wrong with a good old mutex, but putting one in means we would
need to require a thread safe version of Tcl. I don't really
like the "use the JVM to do locking"
Mo DeJong wrote:
Ahh, but Tcl provides a portable locking layer when compiled with
threads support. That is what I am sugesting we use for the mutex.
OK, I hadn't thought of that. (I am trying to augment my Java code with
Tcl, not the other way around... that colors my viewpoint a bit.)
If
So, pardon my desperation, but are you gentlemen going to save my job and give
me a TclBlend 1.2.5 patch to try out?
Jeff Sturm wrote:
Mo DeJong wrote:
Ahh, but Tcl provides a portable locking layer when compiled with
threads support. That is what I am sugesting we use for the mutex.
OK,
