DBD-SQLite-Amalgamation
view release on metacpan or search on metacpan
sqlite-amalgamation.c view on Meta::CPAN
**** Bummer. If you ask me, this is broken. Badly broken. It means** competing threads of the same process. POSIX locks will work fine** to synchronize accessforthreads in separate processes, but not** threads within the same process.**** To workaroundthe problem, SQLitehasto manage file locks internally** on its own. Whenever a new database is opened, we have to find the** specific inode of the database file (the inode is determined by the** st_dev and st_ino fields of thestatstructure that fstat() fills in)** and checkforlocks already existing on that inode. When locks are** created or removed, we have to look atourown internal record of the** locks to seeifanother threadhaspreviously set alockon that same** inode.**** The sqlite3_file structureforPOSIX isnolonger just an integer file** descriptor. It is now a structure that holds the integer file** descriptor and a pointer to a structure that describes the internal** locks on the corresponding inode. There is one locking structure** per inode, soifthe same inode is opened twice, both unixFile structures
sqlite-amalgamation.c view on Meta::CPAN
/* Testingforflock() can give false positives. Soififthe above** test fails, then we fall back to using dot-file style locking.*/returnLOCKING_STYLE_DOTFILE;}#endif/*** If SQLITE_ENABLE_LOCKING_STYLE isdefined, this function Examines the** f_fstypename entry in the statfs structure as returned bystat()for** the filesystemhosting the database file and selects the appropriate** locking style based on its value. Thesevaluesand assignments are** based on Darwin/OSX behavior and have not been thoroughly tested on** other systems.**** If SQLITE_ENABLE_LOCKING_STYLE is notdefined, this function always** returns LOCKING_STYLE_POSIX.*/staticintdetectLockingStyle(sqlite3_vfs*pVfs,
sqlite-amalgamation.c view on Meta::CPAN
intfd, /* The file descriptor used in the key */struct lockInfo **ppLock, /* Return the lockInfo structure here */struct openCnt **ppOpen/* Return the openCnt structure here */){intrc;struct lockKey key1;struct openKey key2;structstatstatbuf;struct lockInfo*pLock;struct openCnt*pOpen;rc = fstat(fd,&statbuf);if( rc!=0 ){#ifdef EOVERFLOWif( errno==EOVERFLOW )returnSQLITE_NOLFS;#endifreturnSQLITE_IOERR;}/* On OS X on an msdos filesystem, the inode number is reported** incorrectlyforzero-size files. See ticket#3260. To work**aroundthis problem (we consider it a bug in OS X, not SQLite)** we always increase the file size to 1 by writing a single byte** prior to accessing the inode number. The one byte written is** an ASCII'S'character which also happens to be the first byte** in the header of every SQLite database. In this way,ifthere** is a race condition such that another threadhasalready populated** the first page of the database,nodamage is done.*/if( statbuf.st_size==0 ){write(fd,"S", 1);rc = fstat(fd,&statbuf);if( rc!=0 ){returnSQLITE_IOERR;}}memset(&key1, 0, sizeof(key1));key1.dev = statbuf.st_dev;key1.ino = statbuf.st_ino;#if SQLITE_THREADSAFEif( threadsOverrideEachOthersLocks<0 ){
sqlite-amalgamation.c view on Meta::CPAN
}}/*** Determine the current size of a file in bytes*/staticintunixFileSize(sqlite3_file*id, i64*pSize){intrc;structstatbuf;assert( id );rc = fstat(((unixFile*)id)->h,&buf);SimulateIOError( rc=1 );if( rc!=0 ){returnSQLITE_IOERR_FSTAT;}*pSize= buf.st_size;/* When opening a zero-size database, the findLockInfo() procedure** writes a single byte into that file in order to workarounda bug** in the OS-X msdos filesystem. In order to avoid problemswithupper** layers, we need to report this file size as zero even though it is
sqlite-amalgamation.c view on Meta::CPAN
#pragma mark Old-School .lock file based lockingstaticintdotlockCheckReservedLock(sqlite3_file*id,int*pResOut) {intr = 1;unixFile*pFile= (unixFile*)id;char*zLockFile= (char *)pFile->lockingContext;if(pFile->locktype != RESERVED_LOCK) {structstatstatBuf;if(lstat(zLockFile,&statBuf) != 0){/* file does not exist, we could have itifwe want it */r = 0;}}*pResOut= r;returnSQLITE_OK;}staticintdotlockLock(sqlite3_file*id,intlocktype) {
sqlite-amalgamation.c view on Meta::CPAN
if(pFile->locktype > NO_LOCK) {pFile->locktype = locktype;/* Always update the timestamp on the old file */utimes(zLockFile, NULL);returnSQLITE_OK;}/* check to seeiflockfile alreadyexists*/structstatstatBuf;if(lstat(zLockFile,&statBuf) == 0){returnSQLITE_BUSY; /* it does, busy */}/* grab an exclusivelock*/fd =open(zLockFile,O_RDONLY|O_CREAT|O_EXCL,0600);if( fd<0 ){/* failed toopen/create the file, someoneelsemay have stolen thelock*/returnSQLITE_BUSY;}close(fd);
sqlite-amalgamation.c view on Meta::CPAN
/* It's odd to simulate an io-error here, but really this is just** using the io-error infrastructure to test that SQLite handles this** function failing.*/SimulateIOError(returnSQLITE_IOERR );azDirs[0] = sqlite3_temp_directory;for(i=0; i<sizeof(azDirs)/sizeof(azDirs[0]); i++){if( azDirs[i]==0 )continue;if(stat(azDirs[i],&buf) )continue;if( !S_ISDIR(buf.st_mode) )continue;if( access(azDirs[i], 07) )continue;zDir = azDirs[i];break;}/* Check that the output buffer is large enoughforthe temporary file** name. If it is not,returnSQLITE_ERROR.*/if( (strlen(zDir) + strlen(SQLITE_TEMP_FILE_PREFIX) + 17) >= nBuf ){
( run in 0.279 second using v1.01-cache-2.11-cpan-c6e0e5ac2a7 )