You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 9, 2023. It is now read-only.
rgb-node can be started as a thread but there is no way (I know of) to stop it
being able to gracefully stop the running thread is useful as it allows the spawning thread to bring operations to a halt in order to perform operations that are not possible while the service is running (e.g. moving files to a new location) or to re-launch the service with another configuration (e.g. different endpoints for other services)
note: the same idea also applies to other services (e.g. stored)
as discussed in a dev call, looks like a sensible way to implement this feature would be to add an API that allows the spawning thread to request a graceful stop, providing some identification token to prove it's the spawning thread (other threads should not be able to do the same)
Yeah, I did a research some time ago which ended up with the concept that there is no way how to stop the thread in Linux/POSIX :( Rust also does not provide an API for that.
The workaround would be to use dedicated messages to the thread with commands to stop, but this has to be done with a different thread managing architecture than the current one. I already work on it (it is a reactor-based architecture which you can find in https://github.com/Cyphernet-WG/rust-netservices) and plan to migrate nodes in a matter of few months. If this issue is not urgent it can wait that time since there is a dedicated "reactor shutdown channel" which gives the result you are asking for.
rgb-node can be started as a thread but there is no way (I know of) to stop it
being able to gracefully stop the running thread is useful as it allows the spawning thread to bring operations to a halt in order to perform operations that are not possible while the service is running (e.g. moving files to a new location) or to re-launch the service with another configuration (e.g. different endpoints for other services)
note: the same idea also applies to other services (e.g. stored)
as discussed in a dev call, looks like a sensible way to implement this feature would be to add an API that allows the spawning thread to request a graceful stop, providing some identification token to prove it's the spawning thread (other threads should not be able to do the same)
@dr-orlovsky could you please implement this API?
The text was updated successfully, but these errors were encountered: