On 17/02/10 20:29, David Teigland wrote:
On Wed, Feb 17, 2010 at 01:23:39PM +, Steven Whitehouse wrote:
While investigating Red Hat bug #537010 I started looking at the dlm's astd
thread. The way in which the "cast" and "bast" requests are queued looked
as if it might cause reordering since
On Wed, Feb 17, 2010 at 01:23:39PM +, Steven Whitehouse wrote:
>
> While investigating Red Hat bug #537010 I started looking at the dlm's astd
> thread. The way in which the "cast" and "bast" requests are queued looked
> as if it might cause reordering since the "bast" requests are always
> de
Hi,
On Wed, 2010-02-17 at 13:43 +, Christine Caulfield wrote:
> One of the reasons that ASTs are delivered in a separate thread was to
> allow ASTs do do other locking operations without causing a deadlock.
> eg. it would allow locks to be dropped or converted inside a blocking
> AST callba
One of the reasons that ASTs are delivered in a separate thread was to
allow ASTs do do other locking operations without causing a deadlock.
eg. it would allow locks to be dropped or converted inside a blocking
AST callback routine.
So maybe either the new code already allows for this or it's
While investigating Red Hat bug #537010 I started looking at the dlm's astd
thread. The way in which the "cast" and "bast" requests are queued looked
as if it might cause reordering since the "bast" requests are always
delivered after any pending "cast" requests which is not always the
correct ord
