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
signature.asc
Description: PGP signature