[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