From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pete Zaitcev Subject: Re: [Patch 4/7] tabled: retry conflicting locks Date: Wed, 20 Jan 2010 13:16:35 -0700 Message-ID: <20100120131635.64346caa@redhat.com> References: <20100114211312.2df3d349@redhat.com> <4B575F2D.3070403@garzik.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4B575F2D.3070403@garzik.org> Sender: hail-devel-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Jeff Garzik Cc: Project Hail List On Wed, 20 Jan 2010 14:53:17 -0500, Jeff Garzik wrote: > On 01/14/2010 11:13 PM, Pete Zaitcev wrote: > > This problem was with us for a while, and even with this fix our start-up > > is not reliable. But at least we will not be 100% guaranteed to hang as > > before when restarting too quickly. So although the whole area needs some > > serious reworking, this specific case was just too annoying to let it > > continue. > This is not correct. CLD has blocking locks. You issue the LOCK op, > and will be notified when you have acquired the lock, possibly hours or > days later. There is no need to retry anything... Meanwhile, there's no way to cancel an outstanding lock requiest short of blowing off the whole session. I'll switch to LOCK when you fix that, but currently TRYLOCK is the only way (which BTW you use in cldcli too). N.B. ncld continues with this approach. In fact currectly it does not even have a method that performs a blocking lock. -- Pete