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
* 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
On Wed, 21 Sep 2005, Guillaume Fougnies wrote:
>So SQLite is not "portable" on some Unix (more precisely on
>recent linux NPTL where file locks seems broken).
SQLite is indeed portable. It works round lock problems as best it can
with the current model. It is the POSIX locking implementations
So SQLite is not "portable" on some Unix (more precisely on
recent linux NPTL where file locks seems broken).
i submitted a patch this month:
http://www.sqlite.org/cvstrac/tktview?tn=1417
Best regards,
Wed, Sep 21, 2005 at 02:56:48PM +0100: Christian Smith wrote:
> On Tue, 20 Sep 2005, Marco
On Tue, 20 Sep 2005, Marco Bambini wrote:
>I know based on http://www.sqlite.org/faq.html#q8 that it is not safe
>to share the same sqlite3 structure between multiple threads.
>But what if I protect its access with a mutex?
>It is safe?
Until recently, by chance, yes, on some platforms. Recent
I know based on http://www.sqlite.org/faq.html#q8 that it is not safe
to share the same sqlite3 structure between multiple threads.
But what if I protect its access with a mutex?
It is safe?
---
Marco Bambini
6 matches
Mail list logo
