[sqlite] Why SQLite lock 510 bytes for shared lock?
Good job! But I think lock a random byte from ?shared byterange? is enough to implement the shared file lock. Locking whole 510 bytes may take a lower performance. Why do you do so? ???:Richard Hippdrh at sqlite.org ???:SQLite mailing listsqlite-users at mailinglists.sqlite.org :2016?4?7?(??)?21:35 ??:Re: [sqlite] Why SQLite lock 510 bytes for shared lock? On 4/7/16, sanhua.zh sanhua.zh at foxmail.com wrote: I found the code and the comment at [unixLock] of os_unix.h is different. The comment say that a shared lock will lock a random byte from ?shared byte range?(which is 510 bytes length). But the code show that it locks the whole ?shared byte range?. The comment is legacy from the locking protocol used by Windows95, which lacks the ability to do a shared file lock. I'll fix the comment. -- D. Richard Hipp drh at sqlite.org ___ sqlite-users mailing list sqlite-users at mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Why SQLite lock 510 bytes for shared lock?
On 4/7/16, sanhua.zh wrote: > > But I think lock a random byte from ?shared byterange? is enough to > implement the shared file lock. Locking whole 510 bytes may take a lower > performance. Why do you do so? > On linux, the time needed to take a file lock is constant, regardless of how many bytes are locked. So there is no performance impact there. I assume other operating systems are similar. The locking protocol was designed in 2001 and cannot be changed because that would be a compatibility break. -- D. Richard Hipp drh at sqlite.org
[sqlite] Why SQLite lock 510 bytes for shared lock?
I found the code and the comment at [unixLock] of os_unix.h is different.
The comment say that a shared lock will lock a random byte from ?shared byte
range?(which is 510 bytes length). But the code show that it locks the whole
?shared byte range?.
It makes me confused. Which one does the right thing?
The comment in os_unix.h
** To obtain a SHARED lock, a read-lock is obtained on the 'pending
** byte'. If this is successful, a random byte from the 'shared byte
** range' is read-locked and the lock on the 'pending byte' released.
The code in os_unix.h
/* Now get the read-lock */
lock.l_start = SHARED_FIRST;
lock.l_len = SHARED_SIZE;
if( unixFileLock(pFile, lock) ){
tErrno = errno;
rc = sqliteErrorFromPosixError(tErrno, SQLITE_IOERR_LOCK);
}
[sqlite] Why SQLite lock 510 bytes for shared lock?
On 4/7/16, sanhua.zh wrote: > I found the code and the comment at [unixLock] of os_unix.h is different. > The comment say that a shared lock will lock a random byte from ?shared byte > range?(which is 510 bytes length). But the code show that it locks the whole > ?shared byte range?. The comment is legacy from the locking protocol used by Windows95, which lacks the ability to do a shared file lock. I'll fix the comment. -- D. Richard Hipp drh at sqlite.org
