Richard, I have to admit i am a little dissapointed. As the primary author of the software i would have thought that you would have a good understanding of what the thread safety characteristics of your own api were.
Suggesting that suppressing the safety checks will result in random and non reproducable failures seems a little extreme, if not superstitious. As i was discussing with Nicholas, api's are not by default thread unsafe. In fact it is the other way around, most api's should be perfectly thread safe if access to them is synchronised. It is my undestanding that sqlite3_stmt * represents an instance of the VM, and that most of the internal virtual machine operations are reentrant, simply operating on the supplied VM and modifying its internal state. If this is the case, i cant see how you would ever have thread safety problems so long as no two threads are modifying the same sqlite3_stmt * at the same time. Surely this is something that can be reasoned through ? Adding deliberate safety check imbalances to sqlite3_step becuase it is the only routine that can be called mutliple times in sequence is a bit extreme. Why not allow users who don't believe in withces and goblins go ahead and use the api in a synchronised way. The safety checks will still be there, just not as agressively. You should also considder that the safety checks only provide a warning for the user. Given that they are subject to race conditions, you can never guarantee that the safety checks will trap all errors. In fact i would argue that you are better off throwing an int 3 instruction than returning a misuse error. Giving the programmer the false idea that they can continue to run their program without stack corruption is not a good idea, after all its just encouraging them to try again. Rather, according to what you are saying they should be re-writing their code to access the api with a single thread. So on the one hand you are actively disallowing users like myself from synchronising thread access to the api, but on the other hand encouraging other users to not fix the actual problems. It doesnt make sense... Im sorry for being so harsh, and i know im not winning any friends here, but i dont give up easily. I think sqlite is an excellent piece of software and i believe there is a way which it can be made to accomodate these concerns. I have tested the changes i made with some 50 threads performing probably thousands of statements a second, and had no errors. If you are willing to work through the problem, i am willing to assist you in any way that i can. Wether it be writing test cases or making modifications to the source. If there are problems as you say, then there is no reason why they cant alteast be documented and verified. Emerson On 1/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
"Emerson Clarke" <[EMAIL PROTECTED]> wrote: > > The problem i had was with sqlite not being compatible with the simple > design that i wanted. I did try several alternate designs, but only > as a way of working around the problem i had with sqlite. It took a > long time but eventually i managed to get someone to explain why > sqlite had that particular problem, and i was able to modify the > sqlite source to resolve the issue. > I remain unconvinced that there is any problem with SQLite in regard to thread safety. It is my belief that by disabling the safety check routines, you are opening your self up to lots of problems. Those routines are there to protect you, the programmer, and to make your programming errors obvious. By disabling those checks, you have not fixed the problem. You have merely suppressed the symptoms so that you will get rare, random failures that cannot be easily reproduced. On your own head be it. -- D. Richard Hipp <[EMAIL PROTECTED]> ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
