[plt-scheme] sqlite.plt seg faults with 370

The Untypers had problems with this a while back. This is my  
hypothesis as to what's going on (although it happened to us a year  
ago so I may be remembering things wrong):

SQLite can be compiled in thread-safe and non-thread-safe modes  
(there's a switch on the compile or make step, I forget which). On  
Etch, the default package is non-thread-safe. The Scheme interface  
doesn't do anything to correct this, and concurrent queries can cause  
segfaults.

You'll probably find that you get more crashes if you're doing lots  
of large queries, like selecting hundreds to thousands of rows as a  
time, because this increases the chance of multiple queries overlapping.

So... you have options:

   - fix things at the C level;
   - fix things at the Scheme level (semaphores / channels / etc);
   - compile your own version of SQLite with thread safety enabled.

You could also try testing your code on OS X - it comes with a thread- 
safe copy SQLite pre-installed.

Cheers,

-- Dave

>> I had the same problem with sqld-sqlite.plt. I fixed it, using
>> semaphores. But now I got to think about it. SQLite uses callbacks
>> from C to Scheme to return query results. Also it uses a callback
>> function to fix locks. Maybe it has something to do with the moving
>> GC (pointers get moved around)?
>
> The foreign implementation use immobile boxes to make sure that
> pointers to Scheme callbacks don't change.  But you need to make sure
> that they are not collected -- for example, avoid (lambda () ...) with
> no additional references as callbacks.
>
> -- 
>           ((lambda (x) (x x)) (lambda (x) (x x)))          Eli  
> Barzilay:
>                   http://www.barzilay.org/                 Maze is  
> Life!
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme