On Thu, 13 Oct 2005, Florian Weimer wrote:
>* Christian Smith:
>
>> IMHO, SQLite should, however, only open a single file per database (based
>> on inode) which should allow threads to override each others locks as the
>> locks will be on a single file.
>
>I think you need multiple file descriptors, otherwise you'd have to
>use pread for accessing pages (or wrap each lseek/read call in a
>mutex).
It's locks on multiple file descriptors to the same file that is causing
the problem. Using pread or locked lseek/read should be satisfactory. So
long as we retain the semantics of the current OsFile* methods, we should
be dandy.
>
>Apart from that, some kind of per-process table which stores the
>device/inode pair and the lock status information should do the trick.
>The sqlite3 struct would contain an index into that table. Each time
>a file lock has to be changed, the thread acquires a global mutex, and
>updates the information in the global lock table. If necessary, POSIX
>file locks are acquired or released.
We already have an abstract pointer, the OsFile*. The sqlite3 structure
should require no changes. OsFile can contain all the required references
to actual file descriptors and locking.
>
>Of course, you can no longer access the same SQLite3 database using
>two sqlite3 objects in the same thread without risking a deadlock, but
>I don't think this is a major problem.
>
There should be no problem assuming the OsFile semantics don't appear to
change.
Christian
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
