Ludovic Courtès <l...@gnu.org> writes:

> Hi,
>
> Christopher Baines <m...@cbaines.net> skribis:
>
>> Previously, if an error occurred, the worker fiber simply never sends a
>> reply. In the case of HTTP requests to Cuirass, where an exception occurs 
>> when
>> performing a database query, the fiber handling the request blocks as it 
>> never
>> gets a response. I think that this has the potential to cause the process to
>> hit file descriptor limits, as the connections are never responded to.
>>
>> This is fixed by responding with the details of the exception, and then
>> throwing it within the fiber that made the call.
>>
>> * src/cuirass/utils.scm (make-worker-thread-channel): Catch exceptions when
>> calling proc.
>> (call-with-worker-thread): Handle receiving exceptions from the worker 
>> thread.
>
> Good catch!
>
>> +                     (put-message reply
>> +                                  (catch
>> +                                    #t
>
> Please put #t on the same line as ‘catch’.  :-)

Ok, I've made this change and pushed as
bb225189fd56d89ec8be926dda269295ccbfe918.

>> +                                    (lambda ()
>> +                                      (apply proc args))
>> +                                    (lambda (key . args)
>> +                                      (cons* 'worker-thread-error key 
>> args))))))
>
> As discussed with others at the Guix Days, it’s probably a good idea to
> distinguish “remote” exceptions from local exceptions like you did (and
> unlike what ‘inferior-eval’ does).
>
> LGTM!

I don't quite follow what you're saying here, so feel free to elaborate,
but it also didn't sound like there was a problem to fix, so I've gone
ahead and pushed.

Thanks for taking a look,

Chris

Attachment: signature.asc
Description: PGP signature

Reply via email to