This post originated from an RSS feed registered with Python Buzz by Ng Pheng Siong. Original Post: SQLite Threading Feed Title: (render-blog Ng Pheng Siong) Feed URL: http://sandbox.rulemaker.net/ngps/rdf10_xml Feed Description: Just another this here thing blog. Latest Python Buzz Posts Latest Python Buzz Posts by Ng Pheng Siong Latest Posts From (render-blog Ng Pheng Siong)

I've gotten both CMUCL 19a and SBCL 0.8.16 to link with libc_r.so on FreeBSD 4. CMUCL craps out on user code early on. SBCL seems to go farther, although it didn't pass its test suite. Without having grovelled through the source of libc, libc_r and the Lisps, let's just say it isn't as simple as I'd wished for.

My motivation for this is my desire to use SQLite in multithreading mode on FreeBSD with these Common Lisp systems.

The other programming systems I'm interested to use SQLite with are Squeak and Smalltalk/X. Let's see:

$ ldd `which squeak`
/usr/local/bin/squeak:
        ...
        libc.so.4 => /usr/lib/libc.so.4 (0x28143000)

$ ldd `which stx`
/usr/local/bin/stx:
        ...
        libc.so.4 => /usr/lib/libc.so.4 (0x281f6000)

Hmmm. I can try the same with these as I have done with CMUCL and SBCL, Or perhaps I can take another approach...

SQLite's source base is small, and almost all its pthread usage is in os_unix.c. Looking through it, the main use (actually it looks like the only use) of pthread functionality is in guarding access to critical file handling code via a single mutex. Reading os_win.c and os_mac.c confirms this: the former uses a Windows CRITICAL_SECTION, the latter a Mac OS MPCriticalRegionID.

Aha! So another Unix C library that does mutexes might do the trick for SQLite's "threading" requirements. One such library is GNU Pth, an LGPL threading library that comes with a pthread API emulator. Let's do it!

... Several minor changes to SQLite source later, I have libsqlite.so built with Pth. Run lsqlite3 again with stock CMUCL. Looks good!