The Artima Developer Community
Sponsored Link

Python Buzz Forum
SQLite Threading FreeBSD CMUCL Oh My!

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Ng Pheng Siong

Posts: 410
Nickname: ngps
Registered: Apr, 2004

Ng Pheng Siong is just another guy with a website.
SQLite Threading FreeBSD CMUCL Oh My! Posted: Oct 28, 2004 10:08 AM
Reply to this message Reply

This post originated from an RSS feed registered with Python Buzz by Ng Pheng Siong.
Original Post: SQLite Threading FreeBSD CMUCL Oh My!
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)

Advertisement

FreeBSD 4's "man pthread" says:

The current FreeBSD POSIX thread implementation is built in the library
libc_r which contains both thread-safe libc functions and the thread
functions.  This library replaces libc for threaded applications.
...
A FreeBSD specific option has been added to gcc to make linking threaded
processes simple.  gcc -pthread links a threaded process against libc_r
INSTEAD OF libc.

(Emphasis mine.)

SQLite uses pthreads on Unix. Its threadsafe operation requires each thread in a process to make a separate call to sqlite_open() and to use only the specific "sqlite" structure returned from the call.

Thus, on FreeBSD, a process that loads a multithreading SQLite shared library libsqlite.so also needs libc_r.so linked in. (The SQLite port builds a non-threading version.)

Here's where it gets fun:

$ ldd `which lisp`
/usr/local/bin/lisp:
        libm.so.2 => /usr/lib/libm.so.2 (0x28085000)
        libc.so.4 => /usr/lib/libc.so.4 (0x280a0000)

I use the following to load my multithreading libsqlite.so into lisp:

  (progn
    (system::load-object-file "/usr/lib/libc_r.so")
    (system::load-object-file *sqlite3-so-load-path*))

The problem is, lisp hits a weird looking error while exiting after using libsqlite.so. This is caused by linking both libc_r.so and libc.so into the same process.

When I build a non-threading libsqlite.so, the error doesn't occur, so I can use that, but it feels like an unreasonable constraint, because I don't yet know how my SQLite-using Lisp program will look like and it may be more natural to use a threading style.

So what to do? Say, I can build a lisp that links to libc_r.so directly. Yeah. That'll do it!

(To be continued.)

Read: SQLite Threading FreeBSD CMUCL Oh My!

Topic: botnet Previous Topic   Next Topic Topic: A tad of TADS [2]: decorations

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use