From: drh Date: Thu, 7 Apr 2016 13:45:20 +0000 (+0000) Subject: Update comments on the unix file locking protocol. No changes to code. X-Git-Tag: version-3.13.0~122 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=f878e6e1a76d0416ffa9987a406bf362cddc4e0e;p=thirdparty%2Fsqlite.git Update comments on the unix file locking protocol. No changes to code. FossilOrigin-Name: 716b20de4306de1653ba5bcdbfb8d210d2d46e1a --- diff --git a/manifest b/manifest index 971e4ecd4c..d741c58439 100644 --- a/manifest +++ b/manifest @@ -1,5 +1,5 @@ -C Remove\san\sunnecessary\sbranch\sin\sthe\ssqlite3LogEstToInt()\sroutine. -D 2016-04-05T23:39:53.536 +C Update\scomments\son\sthe\sunix\sfile\slocking\sprotocol.\s\sNo\schanges\sto\scode. +D 2016-04-07T13:45:20.032 F Makefile.in eba680121821b8a60940a81454316f47a341487a F Makefile.linux-gcc 7bc79876b875010e8c8f9502eb935ca92aa3c434 F Makefile.msc 1f123a0757f6f04f0341accb46457e116817159a @@ -359,7 +359,7 @@ F src/os.c ca10edb445ad2c5fdc7285b49d72bcdf261fa23e F src/os.h 91ff889115ecd01f436d3611f7f5ea4dc12d92f1 F src/os_common.h b2f4707a603e36811d9b1a13278bffd757857b85 F src/os_setup.h c9d4553b5aaa6f73391448b265b89bed0b890faa -F src/os_unix.c b1ccb273771f41dbdbe0ba7c1ad63c38ad5972ec +F src/os_unix.c bde4844f0849cab5924c6a81178f8500774ce76b F src/os_win.c b3ba9573d8d893e70a6a8015bbee572ecf7ffbef F src/os_win.h eb7a47aa17b26b77eb97e4823f20a00b8bda12ca F src/pager.c 38718a019ca762ba4f6795425d5a54db70d1790d @@ -1482,7 +1482,7 @@ F vsixtest/vsixtest.tcl 6a9a6ab600c25a91a7acc6293828957a386a8a93 F vsixtest/vsixtest.vcxproj.data 2ed517e100c66dc455b492e1a33350c1b20fbcdc F vsixtest/vsixtest.vcxproj.filters 37e51ffedcdb064aad6ff33b6148725226cd608e F vsixtest/vsixtest_TemporaryKey.pfx e5b1b036facdb453873e7084e1cae9102ccc67a0 -P fb555c3c2af7f5e62ff839658f4fba7b645d3a68 -R 7154c3cc804ee2fc9b7c1578477c3cf7 +P da81d7afeb0566a09a505ba5fce901e991e4a029 +R c31dba9b364f6a5e65569f6b94115698 U drh -Z c58518044f9cf200f41dd76757fdb4e4 +Z 3e3e5fb3cba3f9bdb43d997a64c47647 diff --git a/manifest.uuid b/manifest.uuid index ca7e7bdc29..5c2f6169fa 100644 --- a/manifest.uuid +++ b/manifest.uuid @@ -1 +1 @@ -da81d7afeb0566a09a505ba5fce901e991e4a029 \ No newline at end of file +716b20de4306de1653ba5bcdbfb8d210d2d46e1a \ No newline at end of file diff --git a/src/os_unix.c b/src/os_unix.c index 6d1bb0b46d..a797541e8f 100644 --- a/src/os_unix.c +++ b/src/os_unix.c @@ -1502,7 +1502,7 @@ static int unixLock(sqlite3_file *id, int eFileLock){ ** lock transitions in terms of the POSIX advisory shared and exclusive ** lock primitives (called read-locks and write-locks below, to avoid ** confusion with SQLite lock names). The algorithms are complicated - ** slightly in order to be compatible with windows systems simultaneously + ** slightly in order to be compatible with Windows95 systems simultaneously ** accessing the same database file, in case that is ever required. ** ** Symbols defined in os.h indentify the 'pending byte' and the 'reserved @@ -1510,8 +1510,14 @@ static int unixLock(sqlite3_file *id, int eFileLock){ ** range', a range of 510 bytes at a well known offset. ** ** 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. + ** byte'. If this is successful, 'shared byte range' is read-locked + ** and the lock on the 'pending byte' released. (Legacy note: When + ** SQLite was first developed, Windows95 systems were still very common, + ** and Widnows95 lacks a shared-lock capability. So on Windows95, a + ** single randomly selected by from the 'shared byte range' is locked. + ** Windows95 is now pretty much extinct, but this work-around for the + ** lack of shared-locks on Windows95 lives on, for backwards + ** compatibility.) ** ** A process may only obtain a RESERVED lock after it has a SHARED lock. ** A RESERVED lock is implemented by grabbing a write-lock on the @@ -1530,11 +1536,6 @@ static int unixLock(sqlite3_file *id, int eFileLock){ ** range'. Since all other locks require a read-lock on one of the bytes ** within this range, this ensures that no other locks are held on the ** database. - ** - ** The reason a single byte cannot be used instead of the 'shared byte - ** range' is that some versions of windows do not support read-locks. By - ** locking a random byte from a range, concurrent SHARED locks may exist - ** even if the locking primitive used is always a write-lock. */ int rc = SQLITE_OK; unixFile *pFile = (unixFile*)id;