"Emerson Clarke" <[EMAIL PROTECTED]> wrote:
> Im not sure that the current situation of forced thread
> incompatibility is better than leaving it up to users to manage the
> threading.  Usually it is assumed that a library is thread unsafe
> unless otherwise specified.
> 
> Developing multithreaded applications is difficult, i wouldnt dispute
> that.  But i do dispute the wisdom of actively making a library
> incompatible with threads.  Sqlite is the first example of such
> behaviour i have seen, it deliberately fails even if the user attempts
> to synchronise concurrent access.

You'll probably get more help in solving your problem if you
can refrain from sophomoric remarks such as the above.

> 
> Surely it would be better to design the api so that it was either
> fully thread safe and blocked on every call to an sqlite_ function
> using its own mutexes, or to simply ensure that it was process safe
> using shared memory.  As i mentioned in a previous reply,
> synchronising sqlite would be no more or less difficult or error prone
> than synchonising a linked list.

The threading design of SQLite is very simple and intuitive.
Multiple threads can be using SQLite at the same time as long
as they are not using the same database connection at the same
time.  This is consistent with most other utility functions.
The qsort() function is threadsafe - you can have two different
threads in qsort() sorting different arrays at the same time.
But it does not work to sort the same array in two threads at
the same time.  In the same way, SQLite allows two different
threads to be working with different database connections at
the same time, but not the same database connection.

What about that is so difficult to understand?

On some older versions of Linux, SQLite is unable to pass
database connections from one thread to another.  But this
is a problem with the threading libraries used in those older
linux versions and is outside the control of SQLite.  I do not
think this issue comes into play here.

> 
> I dont see what is gained by making it not work with threads, so i
> assume that it is becuase of some technical reason rather than a
> design decision.

SQLite does work with threads.  Your comment is based on a false
premise.

--
D. Richard Hipp  <[EMAIL PROTECTED]>


-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------

Reply via email to