[bug#33210] Cuirass: Use a SQLite in single-thread mode

["Clément Lassieur" <clement@lassieur.org>]

Danny Milosavljevic <dannym@scratchpost.org> writes:

> Hi Clément,
>
>> > Yeah, right now users can query something using the web interface while
>> > a build is updating (or running) at the cost of the returned data being
>> > potentially very strange.  
>> 
>> This is quite unlikely.
>
> When testing the cuirass status frontend it happened regularily without
> me trying to make it happen - took quite some time to find the cause, too.

Maybe it happened without me noticing then.  I'll trust you on this :-)

>> No, there are no SQL requests during the build.  There are some before
>> the build, and some after the build.  But they are all short.
>
> Yes, if there is one transaction right before starting the build and another
> transaction at the end of the build, then it's much better.
>
>> > I have to say I liked the external evaluator much more since then all
>> > this complexity would be contained in the external program and it would
>> > just magically work without special-casing any of this stuff.  
>> 
>> The evaluator is still external, I'm not sure what you are talking
>> about.
>
> Hmm, I'll read through the source for a bit.  I was of the impression
> that now the cuirass main process did the updating of the build status
> rather than the evaluator.

Oh, yes, the updating of the build status is done by the main process,
but the evaluator is still external and doesn't query the database.  Why
don't you like that?

>> > It's difficult for guile-sqlite3 to handle SQLITE_BUSY correctly since
>> > sqlite also uses SQLITE_BUSY to indicate errors that you are supposed to
>> > fail on.  
>> 
>> [...]
>> 
>> > Hmmmmmmmm.  I think that can be done.  
>
> I've tried it and it works well enough, although some of the sqlite
> documentation makes it sound like one cannot *just* retry some of the
> calls (for example: sqlite3_step).
>
> It's one of the disadantages of fibers that every C library has to have
> special code in it to support it somehow (if at all) - it means that
> it has to be written in a way to make all calls non-blocking.

Indeed.  I wonder how goroutines deal with this.  Cc'ing Andy.

Clément