contrib/sqlite3/sqlite3.c

1146 ** argument to calls it makes to the xLock() and xUnlock() methods
1223 ** The integer values to xLock() and xUnlock() are one of
1231 ** xLock() increases the lock. xUnlock() decreases the lock.
1301   int (*xUnlock)(sqlite3_file*, int);
15188   return id->pMethods->xUnlock(id, lockType);
27971    UNLOCK,                     /* xUnlock */                                 \
28001   unixUnlock,               /* xUnlock method */
28010   nolockUnlock,             /* xUnlock method */
28019   dotlockUnlock,            /* xUnlock method */
28030   flockUnlock,              /* xUnlock method */
28042   semUnlock,                /* xUnlock method */
28054   afpUnlock,                /* xUnlock method */
28079   proxyUnlock,              /* xUnlock method */
28092   nfsUnlock,                 /* xUnlock method */
29908       conchFile->pMethod->xUnlock((sqlite3_file*)conchFile, SHARED_LOCK);
29959         conchFile->pMethod->xUnlock((sqlite3_file*)conchFile, NO_LOCK);
29983     rc = conchFile->pMethod->xUnlock((sqlite3_file*)conchFile, NO_LOCK);
30332       rc = proxy->pMethod->xUnlock((sqlite3_file*)proxy, eFileLock);
30353       rc = lockProxy->pMethod->xUnlock((sqlite3_file*)lockProxy, NO_LOCK);
34543   winUnlock,                      /* xUnlock */
38698 ** If the VFS xLock() or xUnlock() returns an error other than SQLITE_BUSY
38707 ** This is usually safe. If an xUnlock fails or appears to fail, there may
38714 ** transition, by the same pager or any other). If the call to xUnlock()
38722 ** doesn't know it because of a previous error in xUnlock). If this happens
38727 ** To work around this, if a call to xUnlock() fails when unlocking the
39402 ** or SHARED_LOCK. Regardless of whether or not the call to xUnlock()
73401   0,             /* xUnlock */
73695   0,                /* xUnlock */