From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joel Becker Date: Thu, 20 Mar 2008 14:45:50 -0700 Subject: [Cluster-devel] libdlm dlm_ls_lock_wait() doesn't. In-Reply-To: <20080320143902.GA20088@redhat.com> References: <20080319223511.GB23815@mail.oracle.com> <20080320143902.GA20088@redhat.com> Message-ID: <20080320214550.GA16583@mail.oracle.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, Mar 20, 2008 at 09:39:02AM -0500, David Teigland wrote: > On Wed, Mar 19, 2008 at 03:35:11PM -0700, Joel Becker wrote: > > Folks, > > Another problem I've run into with libdlm - call > > dlm_ls_lock_wait() on a lock that another node holds, and it returns > > instead of blocking. This is not a trylock (LKF_NOQUEUE). Trylocks > > work as expected. A blocking lock attempt does not block, it just > > fails. I haven't had the time to nail it yet, so if you get there > > first, excellent. > > I've tested both threaded and non-threaded dlm_ls_lock_wait() and they > seem to work for me. A mistake that I got hung up on for a while was that > a non-threaded program must link against libdlm_lt, not libdlm. libo2dlm is not threaded, so we use libdlm_lt. I'm getting EAGAIN returned from dlm_ls_lock_wait() - and this is not a trylock. I can reproduce with o2dlm_test. I was about to give you the instructions on doing so, but I realized it's not trivial - you need the stack-user kernel modules and to install the tools. Joel -- "I have never let my schooling interfere with my education." - Mark Twain Joel Becker Principal Software Developer Oracle E-mail: joel.becker at oracle.com Phone: (650) 506-8127