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
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 lock
> -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 pani
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 loc
> > Tcl Blend users should be doing this already.
>
> I have seen several places where this was not done. Instead the code relies
> on the Java GC to invoke the TclObject.release() implicitly in the
> 'finalized() method. In TclBlend's CObject class:
>
> CObject (
> long objPtr)
> {
>
On Mon, 19 Jun 2000, Jeff Sturm wrote:
> 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 c
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 volati
> -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:
> > explicitly free Tcl object
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
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,
> on
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
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 o
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 needs to make some assumption about how the GC w
15 matches
Mail list logo
