Jan-Henrik Haukeland wrote:
On 2. mars. 2008, at 22.09, Paul J Stevens wrote:
I've been thinking about this. This implies that you can't use multiple statements within a single transaction (at least with sqlite). Is that correct? Because that would make code like below invalid, right?
Not necessarily, though a fair chance that it will not work. The indicator is this SQLite error message "SQL statements in progress".
I am aware of that caveat in the docs. Is that a limitation of sqlite per se? Or rather how libzdb talks to sqlite?
The reason I'm asking is because I'm still trying to get a feel for libzdb's behaviour and implicit expectations. A few things I've noticed:
- I can't use Connection_PreparedStatement on a postgresql connection until I've issued a Connection_executeQuery. Doing so segfaults in libzdb. I've reported this one already, and I can easily work around this.
- I'm getting stack corruption and segfaults in certain hotspots in my code that use glib's GObject interface throught the GMime code. Now is GObject a known not-threadsafe interface, and putting mutexes around my calls solves the segfaults. But thing is: my code is (still) single-threaded (apart from the reaper thread). So apparently thread semantics apply even to single-threaded apps when using libzdb. If that is true, I need to start studying on threads pronto because I havent a clue as to how thread(un)safe my code is at the moment.
- Valgrind is generating massive amounts of 'invalid read' warnings in the ResultSet_getXXX code. Whether this results in segfaults is dependent on the backend. The mysql driver appears to segfault where the postgresql driver simply returns null values. I havent yet tested sqlite. I'm left wondering if this too is thread related.
However, since I only just finished the code changes that de-globalize the result and connection pointers (leaving only the pool pointer as a global) I havent had enough time yet to do some thorough backtracking.
keep you posted.