On Mon, 19 Jun 2000, Dr Wes Munsil wrote:
> 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?
The "right" solution is still being worked, but you should be able
to try this patch to see if it cures the deadlock. This patch
will
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.
>
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.)
> I
> -Original Message-
> From: Mo DeJong [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 19, 2000 1:15 PM
> To: [EMAIL PROTECTED]
> Subject: [Tcl Java] RE: [Tcl Java] Re: [Tcl Java] another deadlock
>
> Good point. I think it might actually be better to put a panic()
> in the finalize() me
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?
I don't think so. The ref counting scheme in the Tcl core is
intentionally not thread safe.
--
Jeff Stur
