[Top][All Lists]
[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