chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Optional sqlite3 egg update


From: F. Wittenberger
Subject: Re: [Chicken-users] Optional sqlite3 egg update
Date: Tue, 07 Mar 2006 16:25:50 +0100

Am Dienstag, den 07.03.2006, 14:51 +0000 schrieb Thomas Chust:
> On Tue, 7 Mar 2006, JörgF. Wittenberger wrote:
....
> actually I must admit that I haven't used the SQLite3 egg for a real 
> multithreaded application so far. Nevertheless I have done some testing, 
> which suggests that everything works fine and the program stays responsive 
> under normal circumstances because the SQLite3 logic is indeed very fast 
> and in case a user defined function runs very long, the CHICKEN scheduler 
> does switch to other threads in the meantime.

That's what I haven't been able to locate in the source code.  And that
was what I wanted to learn how it could be done.

RScheme FFI and calling conventions is sort of simillar to chicken.
Porting is merly a mechanical translation job.  Therefore I've been
hoping to get an idea.

The problem with rscheme is that it's runtime is not reentrant.
Therefore I can't use sqlite3_busy_handler to call the Scheme scheduler.

To my understanding chicken should have the same issue with it, and I
can't find any busy-handler in your code either.

So how will it switch to other threads?

> > Therefore I consider to throw much more C code in and associate a
> > pthread per sqlite3 struct, which would perform the actual calls and
> > call back to Scheme, when sqlite3 is done.
> >
> > Do you think this is approach is useful and might be something to do
> > with the chicken egg too?  Or would your experience suggest otherwise,
> > e.g. sqlite beeing so fast, we would rarely notice and I better go back
> > and find out where exactly those sudden delays come from.
> 
> Unfortunately I know nothing about the internals of RScheme, so I can't 
> really judge whether this is a good idea. I can imagine that it would make 
> several optimizations possible, but I can also imagine that in the end the 
> interthread communication and synchronization compensates fully for other 
> optimizations one could have made.

That's what I'm afraid of too.  In the sqlite case.

However it would be worth the effort, if it was a more general for
wrapping any kind of synchronous API.

> I definitely think that the scheme would be hard to implement for CHICKEN, 
> whose C API is not reentrant.

There would have to be exactly one call, which other threads call call
to signal the chicken thread about events.  I don't know whether chicken
already has such a thing.  Do you?

/Jörg




reply via email to

[Prev in Thread] Current Thread [Next in Thread]