nixos-manager
nixos-manager copied to clipboard
pmiddend
rebuild process
When starting a process, such as the rebuild process, we cannot easily run it in the background and emit an event when it’s finished (at least I don’t know how to do that comfortably with gi-gtk-declarative-app-simple). Instead, we are spawning the process (in the background, mind you), then wait for a small amount of time (which doesn’t block the GUI, fortunately) and then emit a “watch” event, which does the same thing, until the process signals completion. It sounds hacky, and it is, but it’s not that bad.
Can you point me to the place in the code, where that happens? I couldn't find it :-/
It sounds to me like this could be handled by forking a completely separate daemon process before any gtk related stuff happens, to which the building gets delegated.
I'm using this pattern of "fork + watch events" a couple of times in the code. It's always in the Update.hs modules, and it's a little confusing, I admit. For example, in src/NixManager/Packages/Update.hs, you have the updateEvent handler for EventTryInstall on line 190. This code is executed when the user presses the "Try install" button in the packages GUI.
In the handler, the dryInstall function is called (defined in NixManager/NixPackages.hs), which spawns a new process and returns the process ID, along with stdout/stderr handles. After spawning the process, EventTryInstallStarted is generated, which sets the state to "We're installing something" and which then starts the EventTryInstallWatch loop, which checks the process for completion, waits, and then emits another EventTryInstallWatch. Graphically:
Note that we do have to regularly do something while the process is running, namely "pulse" the progress bar so GTK indicates something is happening. But if there were a better "framework" to start and monitor processes than writing all these events, that'd be great.
Thanks for the elaborate answer! I will have to look at the code some more to fully grasp this, I think.
Ok, it seems like a sane approach to me. But still it does unnecessarily cause high cpu usage, which probably means that there is some form of polling behaviour hidden in gi-gtk-declarative(-app-simple)? At least your code doesn't look at fault, since it calls threadDelay.