[Nfs-ganesha-devel] [PATCH v5 13/14] locks: skip deadlock detection on FL_FILE_PVT locks

[Frank Filz]

That is exactly the behavior we are trying to avoid with the new private
locks. We are also adding behavior that allows an application to have
multiple threads of the same process to have their own locking context for a
file.

 

Frank

 

From: Richard Hipp [mailto:drh at sqlite.org] 
Sent: Tuesday, January 14, 2014 1:44 PM
To: Andy Lutomirski
Cc: Richard Hipp; Jeff Layton; samba-technical;
linux-kernel at vger.kernel.org; Linux FS Devel; nfs-ganesha-devel
Subject: Re: [Nfs-ganesha-devel] [PATCH v5 13/14] locks: skip deadlock
detection on FL_FILE_PVT locks

 

 

 

On Tue, Jan 14, 2014 at 4:24 PM, Andy Lutomirski <luto at amacapital.net
<mailto:luto at amacapital.net> > wrote:

On Tue, Jan 14, 2014 at 1:21 PM, Richard Hipp <drh at sqlite.org
<mailto:drh at sqlite.org> > wrote:
> I have no context here.  I'm not sure what you are discussing or what
> questions you have or what SQLite has to do with any of it.  Nevertheless,
I
> have injected a few remarks inline....
>

The discussion is about a new set of fcntl locking commands that are
are respect locks acquired with the old ones but suck less.  This
seems like the right time to discuss what would make them even better.
 The immediate change is to let them be owned by the fd instead of the
process.

This might end up in POSIX and could make sqlite (and lots of other
things') lives easier.



 

Sounds great. 

A common cause of SQLite database corruption is when another application
thread does close(open(zDatabaseFile)) and deletes all of SQLite's locks out
from under it.  (Usually that happens in a misguided attempt to backup the
database.).

Any help we can get in that area will be appreciated!



-- 
D. Richard Hipp
drh at sqlite.org <mailto:drh at sqlite.org>