Richard, First let me say thank you for your earilier suggestion regarding the compile time options and overlaoding of the os routines. It was exactly the kind of information i was searching to for and i am looking into using that strategy at the moment.
Sorry if ive managed to offend you, please excuse my enthusiasm. Its just the way i write and it doesnt necessarily reflect my intentions. I only meant to point out that it is very rare to encounter a library which behaves in the way that sqlite does. That is that the actual pod types cannot be used across multiple threads. I understand that sqlite can be used with multiple threads, but only in what i percieve to be a limited way. I cannot use one connection with multiple threads. So i cant take advantage of the caching unless i use other options and pragma directives. I also cannot perform multiple operations within a single transaction across multiple threads. This design is restrictive in that it forces very granular transactions which then limit the overall performance. Perhaps you could assist me in understanding why this design is better than say, just allowing one connection to be shared amongst threads and letting the user handle the synchronisation ? At the moment there is no way which i can wrap the sqlite libraries in an api which is shared with another database like mysql and have consistent behaviour. This is purely because of the restrictions on the way sqlite handles threads and the fact that a transaction cannot be used across multiple threads. If sqlite behaved differently then from the wrapper code there would be no difference between using sqlite and mysql except for the sql syntax. The fact that it is an embedded file based database would be completely transparent. At the moment it is not. Functions like qsort() are not only thread safe, but probably also reentrant. Im aware of the differences and i understand why things are and arent thread safe. Of course there are several algorithms other than quick sort which can be used to sort the same array in multiple threads. I dont wish to start a debate, merely to engange in a technical discussion of the design which sqlite uses since i dont understand the reasons behind it and i would very much like too. Emerson On 12/29/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
"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] -----------------------------------------------------------------------------
----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
