bonsai: add a noop delay transition at the root of the state machine, hopefully improves reliability
This commit is contained in:
@@ -53,7 +53,21 @@ in
|
|||||||
# plug into the (proposed) nixpkgs bonsaid service.
|
# plug into the (proposed) nixpkgs bonsaid service.
|
||||||
# it's a user service, and since i don't use the service manager it doesn't actually activate:
|
# it's a user service, and since i don't use the service manager it doesn't actually activate:
|
||||||
# i just steal the config file generation from it :)
|
# i just steal the config file generation from it :)
|
||||||
services.bonsaid.settings = lib.mkIf cfg.enabled cfg.config.transitions;
|
services.bonsaid.settings = lib.mkIf cfg.enabled (lib.mkMerge [
|
||||||
|
cfg.config.transitions
|
||||||
|
[{
|
||||||
|
type = "delay";
|
||||||
|
transitions = [];
|
||||||
|
# speculative: i've observed a hang inside bonsai (rather, hare-ev) where it
|
||||||
|
# attempts to read from a timer, assuming it to have expired, and the read *never* returns.
|
||||||
|
# i think this can happen when an `exec` and a `delay` trigger simultaneously?
|
||||||
|
# particularly, hare-ev does the exec action callback, during which bonsaid enters a node w/o delay and *disables* the timer, and then reading the timer hangs.
|
||||||
|
# if true, then adding a delay to the root node alleviates that (so long as all other nodes also have delays).
|
||||||
|
#
|
||||||
|
# long term, it may be best to move away from bonsai. aside from the above, it's really easy to get it to segfault.
|
||||||
|
delay_duration = 30000 * 1000000;
|
||||||
|
}]
|
||||||
|
]);
|
||||||
# vvv not actually necessary. TODO: delete this line once the service is upstreamed?
|
# vvv not actually necessary. TODO: delete this line once the service is upstreamed?
|
||||||
services.bonsaid.enable = lib.mkIf cfg.enabled true;
|
services.bonsaid.enable = lib.mkIf cfg.enabled true;
|
||||||
}
|
}
|
||||||
|
Reference in New Issue
Block a user