Hi,
I posted a question a few days ago on the cause of getting
SQLITE_MISUSE when I called sqlite3_prepare_v2. I thought I both ruled
out the possibilites advised by the replies and solved the probelm by
finalizing statements on the sqlite_master table earlier.
Well the problem didn't get solved this way (as my hunch told me).
What really happened surprised me. Again I was wondering the root
cause of it.
It turned out that I have the following execution history:
Time Thread A Thread B
0 prepare foo
1 prepare bar
2 finalize foo
3 step bar
4 finalize bar
5 prepare baz (*)
(*) indicates that I started getting SQLITE_MISUSE from this point on.
In essence, a statement prepared in Thread A was finalized in-between
a prepare-finalize block running in Thread B.
After that, when I prepared another statement in Thread A, I started
getting SQLITE_MISUSE. And all subsequent sqlite3_prepare calls
returned the same.
One interesting thing about my code was that statement foo wasn't
really used. It was prepared by some parent class init code, and was
discarded by child class's init. As it turned out, I didn't
immediately call sqlite3_finalize(foo). Rather I threw the object in a
deferred release pool (auto object management, or autorelease pool in
Objective-C speak). Finalize could be called before Thread B's prepare-
finalize block started or during the block, as is the nature of
threaded execution.
My code broke every time when the execution history exhibited a
pattern like above. Finalizing foo right before Thread B's prepare-
finalize block stopped the problem. I no longer get SQLITE_MISUSE.
I'm still wondering why it is impossible to call sqlite3_finalize in a
situation like this. The document doesn't seem to warn against it
(although the doc warns the evilness of threading in general). Or is
the root cause deeper?
Thanks again.
d.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
