| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
| |
There seems to be some issue which can lead to the client and agent ports no
longer being listened on. I've got no idea how to track this down, so just try
and monitor for it and kill the process if it happens.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Not sure what this does, but it seems to work around Guile crashing
in (backtrace) like:
Backtrace:
In guix-build-coordinator/utils/fibers.scm:
Exception thrown while printing backtrace:
In procedure vector-ref: Argument 2 out of range: 99
|
| |
|
|
| |
Add some top level exception handling to guard against errors anywhere.
|
| |
|
|
| |
In the worker threads.
|
| | |
|
| |
|
|
|
| |
Otherwise operations can build up while the thread pool is busy, and this'll
hopefully make it clearer when there are issues with the thread pools.
|
| | |
|
| | |
|
| |
|
|
|
| |
I think the main change required is just to stop accessing the now missing
current-fiber parameter.
|
| |
|
|
| |
Mostly copied from the Guix Data Service.
|
| | |
|
| |
|
|
|
| |
As some exceptions can be expected, like chunked responses being incomplete,
so allow reducing the unnecessary output.
|
| |
|
|
| |
So this can be logged.
|
| |
|
|
|
| |
Don't keep database connections around forever as this relates to cached query
plans, and also run the optimize pragma when closing connections.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
With with-exception-handler being called with #:unwind? #f (implicitly). This
breaks Guile internals used by (backtrace) [1], meaning you get a different
exception/backtrace when Guile itself breaks.
This should avoid the "string->number: Wrong type argument in position
1 (expecting string): #f" exception I've been haunted by for the last year.
1: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46009
|
| | |
|
|
|
To start making it possible to use the agent, without having to load anything
related to fibers (as it doesn't work on the hurd yet).
|