[Announce] libzdb 2.1
Paul J Stevens
paul at nfg.nl
Mon Mar 3 09:44:00 CET 2008
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.
--
________________________________________________________________
Paul Stevens paul at nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands________________________________http://www.nfg.nl
More information about the libzdb-general
mailing list