Re: [PATCH 1/2] Support publishing build events

[Christopher Baines]

I've finally got back around to looking at this again, I've sent a new
v4 version which is a slimmed down version of the previous patch. The
events table itself is now used as the queue, with sent events being
deleted. The table is also only populated if the --record-events option
is set when running Cuirass.


Clément Lassieur <address@hidden> writes:

>>>>> But in that case, why not fetch them from the Guix Data Service?
>>>>
>>>> I'm still not sure what the ideal scope and architecture for the Guix
>>>> Data Service, or Cuirass is, but at the moment I've been trying to avoid
>>>> making one dependent on the other.
>>>
>>> Well, if we want to keep our softwares (GDS and Cuirass) as simple as
>>> they can be, there should be a clear delimitation about what each of
>>> them does, and they should not implement the same features, in my
>>> opinion.
>>
>> At least in my mind, this is an important issue, but something I'm very
>> uncertian about. The biggest existing overlap in my mind is that the
>> Guix Data Service and Cuirass compute and store derivations.
>>
>>> Also, I can't see how GDS wouldn't be dependent on Cuirass.
>>
>> Maybe dependent wasn't the best way to phrase it. What I've been
>> thinking about is you should be able to run Cuirass without the Guix
>> Data Service, and this might be very applicable for small deployments.
>
> Oh yes, of course, I see.  That's why I was talking about an option to
> enable/disable DB-ADD-EVENT in my other email.

I've now added this option, through the --record-events parameter.

...

>>>>> Why do we need to use a fiber, if there is only one?  A fiber is a
>>>>> lightweight thread.  They are useful if we need to do several things in
>>>>> the same time, but if there is only one thing to do, I don't understand
>>>>> the point.
>>>>
>>>> If I remember correctly, the way Cuirass accesses the database is tied
>>>> up with fibers, so it's to make the database access work here.
>>>
>>> It's not tied up with fibers.  There is a database server in another
>>> thread, and WITH-DB-CRITICAL-SECTION will allow you to communicate with
>>> that server through channels.  But you don't need to be in a fiber to
>>> communicate through channels, being in the main thread is good enough.
>>
>> Ok, I'll have another look at how fibers are used when sending out
>> events.
>
> It's just a few lines to remove, nothing troublesome I believe.

Yeah, so after trying this out, it does indeed work fine without using
fibers.

signature.asc
Description: PGP signature