From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@labs.coraid.com>
Date: Wed, 17 Nov 2010 02:03:30 -0500
To: lucio@proxima.alt.za, 9fans@9fans.net
Message-ID: <48d5f7105e73eb21f0dc5886c4decb4f@coraid.com>
In-Reply-To: <20101117064838.GB3597@fangle.proxima.alt.za>
References: <1e1e3d7c4781c86aa3a270cecdbaadbb@coraid.com>
	<875ae24babf9d402d55084c7dad708c0@gmx.de>
	<20101117064838.GB3597@fangle.proxima.alt.za>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] That deadlock, again
Topicbox-Message-UUID: 83eab03e-ead6-11e9-9d60-3106f5b1d025

> On Wed, Nov 17, 2010 at 06:33:13AM +0100, cinap_lenrek@gmx.de wrote:
> > sorry for not being clear.  what i ment was that qpc is for the last
> > qlock we succeeded to acquire.  its *not* the one we are spinning on.
> > also, qpc is not set to nil on unlock.
> >
> Ok, so we set qpctry (qpcdbg?) to qpc before changing qpc?  Irrespective
> of whether qpc is set or nil?  And should qunlock() clear qpc for safety,
> or would this just make debugging more difficult?

no.  you're very likely to nil out the new qpc if you do that.

- erik