lib/sqlite/sqlite3.c

1084 ** argument to calls it makes to the xLock() and xUnlock() methods
1161 ** The integer values to xLock() and xUnlock() are one of
1169 ** xLock() increases the lock. xUnlock() decreases the lock.
1239   int (*xUnlock)(sqlite3_file*, int);
14421   return id->pMethods->xUnlock(id, lockType);
23799   os2Unlock,                      /* xUnlock */
28856    UNLOCK,                     /* xUnlock */                                 \
28884   unixUnlock,               /* xUnlock method */
28893   nolockUnlock,             /* xUnlock method */
28902   dotlockUnlock,            /* xUnlock method */
28913   flockUnlock,              /* xUnlock method */
28925   semUnlock,                /* xUnlock method */
28937   afpUnlock,                /* xUnlock method */
28962   proxyUnlock,              /* xUnlock method */
28975   nfsUnlock,                 /* xUnlock method */
30750       conchFile->pMethod->xUnlock((sqlite3_file*)conchFile, SHARED_LOCK);
30802         conchFile->pMethod->xUnlock((sqlite3_file*)conchFile, NO_LOCK);
30826     rc = conchFile->pMethod->xUnlock((sqlite3_file*)conchFile, NO_LOCK);
31175       rc = proxy->pMethod->xUnlock((sqlite3_file*)proxy, eFileLock);
31196       rc = lockProxy->pMethod->xUnlock((sqlite3_file*)lockProxy, NO_LOCK);
33892   winUnlock,                      /* xUnlock */
37902 ** If the VFS xLock() or xUnlock() returns an error other than SQLITE_BUSY
37911 ** This is usually safe. If an xUnlock fails or appears to fail, there may
37918 ** transition, by the same pager or any other). If the call to xUnlock()
37926 ** doesn't know it because of a previous error in xUnlock). If this happens
37931 ** To work around this, if a call to xUnlock() fails when unlocking the
38582 ** or SHARED_LOCK. Regardless of whether or not the call to xUnlock()
71342   0,             /* xUnlock */
71626   0,                /* xUnlock */