Hello all,
I am reposting the following question. Any input would be
much appreciated, as it will help speed my port of SQLite
to my company's embedded platform.
(I am trying to sell my company on SQLite; if I succeed,
every cable television customer in the UK will soon be
using SQLite!)
-------------------------------------------------------------
I am porting SQLite 3.5.x to an embedded OS, and am trying to
figure out how to implement xLock(), xUnlock(), and xCheck-
ReservedLock().
My target OS doesn't have any file locking primitives, so I
intend to implement the locking using a hash table of lockInfo
structs, along with pLock and locktype fields in the file
descriptor [similar to what unixLock() does].
The xLock() function has the following prototype:
static int xLock(sqlite3_file *id, int locktype);
where 'id' is a pointer to an open file descriptor belonging to a
process (or thread) attached to the database file, and 'locktype'
is the type of lock (SHARED, RESERVED, PENDING, or EXCLUSIVE)
that the process would *like* to acquire.
It is assumed that xLock() has some way of knowing and updating
not only the current lock type held by the process, but also the
current lock state of the database file.
In my implementation of xLock(), as in unixLock(), the current
lock type held by the process will be in id->locktype, and the
current lock state of the file will be in id->pLock (a pointer
to the lockInfo struct for that file).
I am thinking of writing xLock() so that it handles *all possible*
locking transitions requested by a process, regardless of whether
or not they will actually occur in practice:
UNLOCKED -> SHARED
UNLOCKED -> RESERVED
UNLOCKED -> PENDING
UNLOCKED -> EXCLUSIVE
SHARED -> RESERVED
SHARED -> PENDING
SHARED -> EXCLUSIVE
RESERVED -> PENDING
RESERVED -> EXCLUSIVE
PENDING -> EXCLUSIVE
For example, if a database file is UNLOCKED, and an attached
process wants to go from UNLOCKED straight to EXCLUSIVE, it
seems perfectly safe to let him do it, even though the doc-
umentation states that a process wanting an EXCLUSIVE lock
always acquires a SHARED lock first.
In other words, I am thinking of coding xLock() so that it
allows all legal transitions (and disallows all illegal ones),
but has no knowledge of the pager's policies regarding trans-
itions.
That is, I want a strict separation between OS-level policies
(what is legal from the point of view of the lock state defin-
itions) and pager-level policies (what is actually done in
practice).
Does this seem like a reasonable idea? More importantly,
will it work (not break SQLite)?
Thanks,
Richard Klein
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
