README.md in async-container-0.15.0 vs README.md in async-container-0.16.0
- old
+ new
@@ -1,10 +1,10 @@
# Async::Container
Provides containers which implement concurrency policy for high-level servers (and potentially clients).
-[](http://travis-ci.org/socketry/async-container)
+[](https://github.com/socketry/async-container/actions?workflow=Development)
[](https://codeclimate.com/github/socketry/async-container)
[](https://coveralls.io/r/socketry/async-container)
## Installation
@@ -22,23 +22,90 @@
$ gem install async
## Usage
+### Container
+
+A container represents a set of child processes (or threads) which are doing work for you.
+
```ruby
-container = Async::Container::Threaded.new
+require 'async/container'
-container.run(count: 8)
- # 8 reactors will be spawned, in separate threads.
- Server.new.run(...)
+Async.logger.debug!
+
+container = Async::Container.new
+
+container.async do |task|
+ task.logger.debug "Sleeping..."
+ task.sleep(1)
+ task.logger.debug "Waking up!"
end
-container = Async::Container::Forked.new
+Async.logger.debug "Waiting for container..."
+container.wait
+Async.logger.debug "Finished."
+```
-container.run(count: 8) do
- # 8 reactors will be spawned, in separate forked processes.
- Server.new.run(...)
+### Controller
+
+The controller provides the life-cycle management for one or more containers of processes. It provides behaviour like starting, restarting, reloading and stopping. You can see some [example implementations in Falcon](https://github.com/socketry/falcon/blob/master/lib/falcon/controller/). If the process running the controller receives `SIGHUP` it will recreate the container gracefully.
+
+```ruby
+require 'async/container'
+
+Async.logger.debug!
+
+class Controller < Async::Container::Controller
+ def setup(container)
+ container.async do |task|
+ while true
+ Async.logger.debug("Sleeping...")
+ task.sleep(1)
+ end
+ end
+ end
end
+
+controller = Controller.new
+
+controller.run
+
+# If you send SIGHUP to this process, it will recreate the container.
+```
+
+### Signal Handling
+
+`SIGINT` is the interrupt signal. The terminal sends it to the foreground process when the user presses **ctrl-c**. The default behavior is to terminate the process, but it can be caught or ignored. The intention is to provide a mechanism for an orderly, graceful shutdown.
+
+`SIGQUIT` is the dump core signal. The terminal sends it to the foreground process when the user presses **ctrl-\**. The default behavior is to terminate the process and dump core, but it can be caught or ignored. The intention is to provide a mechanism for the user to abort the process. You can look at `SIGINT` as "user-initiated happy termination" and `SIGQUIT` as "user-initiated unhappy termination."
+
+`SIGTERM` is the termination signal. The default behavior is to terminate the process, but it also can be caught or ignored. The intention is to kill the process, gracefully or not, but to first allow it a chance to cleanup.
+
+`SIGKILL` is the kill signal. The only behavior is to kill the process, immediately. As the process cannot catch the signal, it cannot cleanup, and thus this is a signal of last resort.
+
+`SIGSTOP` is the pause signal. The only behavior is to pause the process; the signal cannot be caught or ignored. The shell uses pausing (and its counterpart, resuming via `SIGCONT`) to implement job control.
+
+### Integration
+
+#### systemd
+
+Install a template file into `/etc/systemd/system/`:
+
+```
+# my-daemon.service
+[Unit]
+Description=My Daemon
+AssertPathExists=/srv/
+
+[Service]
+Type=notify
+WorkingDirectory=/srv/my-daemon
+ExecStart=bundle exec my-daemon
+Nice=5
+
+[Install]
+WantedBy=multi-user.target
```
## Contributing
1. Fork it