github.com/kaluza-tech/rununtil
Package rununtil has been created to run a provided function until it has been signalled to stop. The main usage of rununtil is to run your main app indefinitely until a SIGINT or SIGTERM signal has been received. The `AwaitKillSignal` is a blocking function which waits until a kill signal has been received. It takes in `RunnerFunc`s which are nonblocking functions which set off go routines (e.g. to run an HTTP server or a gRPC server) and return a `ShutdownFunc`. The `ShutdownFunc`s are executed when a kill signal has been received to allow for graceful shutdown of the go routines set off by the `RunnerFunc`s. For example: The `AwaitKillSignal` function blocks until either a kill signal has been received or `CancelAll` has been triggered. A nice pattern is to create a function that takes in the various depencies required, for example, a logger (but could be anything, e.g. configs, database, etc.), and returns a runner function: It is of course possible to specify which signals you would like to use to kill your application using the `AwaitKillSignals` function, for example: For testing purposes you may want to run your main function, which is using `rununtil.AwaitKillSignal`, and then kill it by simulating sending a kill signal when you're done with your tests. To aid with this you can: The `CancelAll` function results in the same behaviour as sending a real kill signal to your program would, i.e.~graceful shutdown is initiated. The old functions `KillSignal`, `Signals` and `Killed` are still here (for backwards compatibility), but they have been deprecated. Please use `AwaitKillSignal` instead of `KillSignal`, `AwaitKillSignals` instead of `Signals`, and `CancelAll` instead of `Killed` (now you can just run in a go routine main and then execute `CancelAll` to finish the `AwaitKillSignal`).
Readme
Go library to run a function until a kill signal is recieved.
See the docs: https://godoc.org/github.com/mec07/rununtil
The CHANGELOG.md file tracks all of the changes and each release.
We are managing it using the helpful changelog-tool.
On Mac you can install it with brew: brew install kaluza-tech/devint/changelog-tool.
On linux (or any other platform) you have to install the pony language.
Then just follow the instructions on the github page for installing the changelog-tool:
https://github.com/ponylang/changelog-tool#installation
The use of the tool is straightforward. To create a new changelog (don't run this in this repo because then you'll replace the current changelog with a new one!):
changelog-tool new
To start recording a new entry:
changelog-tool unreleased -e
The -e means update the changelog file in place.
Then manually edit the changelog to add your changes in the unreleased section.
When you're ready you can then "release" it by executing:
changelog-tool release 0.0.1 -e
Replace 0.0.1 with the new version.
FAQs
Package rununtil has been created to run a provided function until it has been signalled to stop. The main usage of rununtil is to run your main app indefinitely until a SIGINT or SIGTERM signal has been received. The `AwaitKillSignal` is a blocking function which waits until a kill signal has been received. It takes in `RunnerFunc`s which are nonblocking functions which set off go routines (e.g. to run an HTTP server or a gRPC server) and return a `ShutdownFunc`. The `ShutdownFunc`s are executed when a kill signal has been received to allow for graceful shutdown of the go routines set off by the `RunnerFunc`s. For example: The `AwaitKillSignal` function blocks until either a kill signal has been received or `CancelAll` has been triggered. A nice pattern is to create a function that takes in the various depencies required, for example, a logger (but could be anything, e.g. configs, database, etc.), and returns a runner function: It is of course possible to specify which signals you would like to use to kill your application using the `AwaitKillSignals` function, for example: For testing purposes you may want to run your main function, which is using `rununtil.AwaitKillSignal`, and then kill it by simulating sending a kill signal when you're done with your tests. To aid with this you can: The `CancelAll` function results in the same behaviour as sending a real kill signal to your program would, i.e.~graceful shutdown is initiated. The old functions `KillSignal`, `Signals` and `Killed` are still here (for backwards compatibility), but they have been deprecated. Please use `AwaitKillSignal` instead of `KillSignal`, `AwaitKillSignals` instead of `Signals`, and `CancelAll` instead of `Killed` (now you can just run in a go routine main and then execute `CancelAll` to finish the `AwaitKillSignal`).
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Cyber extortion in the US and Canada hit record levels in 2023, with ransomware attacks surging and median ransom demands skyrocketing, though fewer companies are choosing to pay ransoms.
Security News
Ecma TC39 is meeting this week and has moved key ECMAScript proposals forward, advancing Deferred Import Evaluation, Error.isError(), RegExp Escaping, and Promise.try to the next stages.
Security News
Researchers have demonstrated that teams of LLM agents can exploit zero-day vulnerabilities with a 53% success rate, and the costs of using AI to do so are rapidly becoming more affordable than hiring a human penetration tester.