Emerson, one posts to a forum like this to get help and other ideas, not
to spark a debate. Many talented people gave you some of their time to
help you solve your problem and one in particular gave you a well
conceived and executed piece of software free of charge. Appreciate
their charity.
If you have some insights which have escaped the rest of us, implement
them and present the results to the world and dazzle us.
BTW, a major advantage of Open Source software is that you do not need
to have people explain it to you. You have the source and that explains
everything. That is particularly so with Sqlite, which is clearly
written and consequently the source reads like a book. A few minutes
with the source and grep and you have your answers.
Emerson Clarke wrote:
John,
Um, alright then...
But i think your preaching to the converted, simplifying things is
what i always try to do. And not just when theres a problem....
If you followed the thread fully you would realise that there was
never a problem with my design, though that didnt stop many people
from chirping in and offering suggestions.
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.
Unfortunately no one has yet commented on my solution, or the problem
which it addresses. Basically sqlite has thread safety checking
routines which work a little like mutexe's. Every time you enter a
bit of code which is potentially thread unsafe it sets a magic number,
then resets it when it comes out. This is an attempt to detect when
two threads are accessing the same bit of code at the same time.
Clearly its not 100% reliable, and is subject to all kinds of thread
races, but it does provide some measure of protection. Unfortunately
though, the way it has been coded, an unbalanced safety check is
performed in the sqlite3_step() function.
This is equivalent to entering a mutex but never leaving, which causes
deadlock in a multithreaded program. Only in this situation sqlite
throws a misuse error any time two or more threads use sqlite3_step()
at the same time, even if those threads are synchronised and perfectly
safe.
The easy solution is to disable the safety checks, the propper
solution is to balance out the checks in sqlite3_step() so that users
who actually wish to use sqlite in a multithreaded program are free to
synchronise access to the api without error and there is still a
reasonable level of safety checking for users who do not synchronise
properly.
Emerson
On 1/5/07, John Stanton <[EMAIL PROTECTED]> wrote:
Work on turning "reasonable" into "adequate" or "good" and it will help
you get an intuitive feel for the design of programs such as yours.
Then your programs will be simple, fast and robust, as Einstein
counselled - "Make it as simple a possible, but no simpler".
I also suggest that you take Niklaus Wirth's advice and when you run
into a difficulty backtrack your work and scrap everything until you
reach a point where there are no problems and start again from that
point taking a different approach having learned a lesson from your
previous attempt.
By the way, I doubt whether you are using a modern operating system, it
is most likely to be old technology like Windows or Linux. Neither
supports much in the way of parallelism.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
