Skip to content

Commit 5dfdafd

Browse files
committed
Bump patch version.
1 parent 44da6af commit 5dfdafd

File tree

5 files changed

+185
-1
lines changed

5 files changed

+185
-1
lines changed

context/getting-started.md

Lines changed: 102 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,102 @@
1+
# Getting Started
2+
3+
This guide explains how to use `async-container` to build basic scalable systems.
4+
5+
## Installation
6+
7+
Add the gem to your project:
8+
9+
~~~ bash
10+
$ bundle add async-container
11+
~~~
12+
13+
## Core Concepts
14+
15+
`async-container` has several core concepts:
16+
17+
- {ruby Async::Container::Forked} and {ruby Async::Container::Threaded} are used to manage one or more child processes and threads respectively for parallel execution. While threads share the address space which can reduce overall memory usage, processes have better isolation and fault tolerance.
18+
- {ruby Async::Container::Controller} manages one or more containers and handles graceful restarts. Containers should be implemented in such a way that multiple containers can be running at the same time.
19+
20+
## Containers
21+
22+
A container represents a set of child processes (or threads) which are doing work for you.
23+
24+
``` ruby
25+
require "async/container"
26+
27+
Console.logger.debug!
28+
29+
container = Async::Container.new
30+
31+
container.spawn do |task|
32+
Console.debug task, "Sleeping..."
33+
sleep(1)
34+
Console.debug task, "Waking up!"
35+
end
36+
37+
Console.debug "Waiting for container..."
38+
container.wait
39+
Console.debug "Finished."
40+
```
41+
42+
### Stopping Child Processes
43+
44+
Containers provide three approaches for stopping child processes (or threads). When you call `container.stop()`, a progressive approach is used:
45+
46+
- **Interrupt** means **"Please start shutting down gracefully"**. This is the gentlest shutdown request, giving applications maximum time to finish current work and cleanup resources.
47+
48+
- **Terminate** means **"Shut down now"**. This is more urgent - the process should stop what it's doing and terminate promptly, but still has a chance to cleanup.
49+
50+
- **Kill** means **"Die immediately"**. This forcefully terminates the process with no cleanup opportunity. This is the method of last resort.
51+
52+
The escalation sequence follows this pattern:
53+
1. interrupt → wait for timeout → still running?
54+
2. terminate → wait for timeout → still running?
55+
3. kill → process terminated.
56+
57+
This gives well-behaved processes multiple opportunities to shut down gracefully, while ensuring that unresponsive processes are eventually killed.
58+
59+
**Implementation Note:** For forked containers, these methods send Unix signals (`SIGINT`, `SIGTERM`, `SIGKILL`). For threaded containers, they use different mechanisms appropriate to threads. The container abstraction hides these implementation details.
60+
61+
## Controllers
62+
63+
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.
64+
65+
``` ruby
66+
require "async/container"
67+
68+
Console.logger.debug!
69+
70+
class Controller < Async::Container::Controller
71+
def create_container
72+
Async::Container::Forked.new
73+
# or Async::Container::Threaded.new
74+
# or Async::Container::Hybrid.new
75+
end
76+
77+
def setup(container)
78+
container.run count: 2, restart: true do |instance|
79+
while true
80+
Console.debug(instance, "Sleeping...")
81+
sleep(1)
82+
end
83+
end
84+
end
85+
end
86+
87+
controller = Controller.new
88+
89+
controller.run
90+
91+
# If you send SIGHUP to this process, it will recreate the container.
92+
```
93+
94+
### Controller Signal Handling
95+
96+
Controllers are designed to run at the process level and are therefore responsible for processing signals. When your controller process receives these signals:
97+
98+
- `SIGHUP` → Gracefully reload the container (restart with new configuration).
99+
- `SIGINT` → Begin graceful shutdown of the entire controller and all children.
100+
- `SIGTERM` → Begin immediate shutdown of the controller and all children.
101+
102+
Ideally, do not send `SIGKILL` to a controller, as it will immediately terminate the controller without giving it a chance to gracefully shut down child processes. This can leave orphaned processes running and prevent proper cleanup.

context/index.yaml

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
# Automatically generated context index for Utopia::Project guides.
2+
# Do not edit then files in this directory directly, instead edit the guides and then run `bake utopia:project:agent:context:update`.
3+
---
4+
description: Abstract container-based parallelism using threads and processes where
5+
appropriate.
6+
metadata:
7+
documentation_uri: https://socketry.github.io/async-container/
8+
source_code_uri: https://github.com/socketry/async-container.git
9+
files:
10+
- path: getting-started.md
11+
title: Getting Started
12+
description: This guide explains how to use `async-container` to build basic scalable
13+
systems.
14+
- path: systemd-integration.md
15+
title: Systemd Integration
16+
description: This guide explains how to use `async-container` with systemd to manage
17+
your application as a service.
18+
- path: kubernetes-integration.md
19+
title: Kubernetes Integration
20+
description: This guide explains how to use `async-container` with Kubernetes to
21+
manage your application as a containerized service.

context/kubernetes-integration.md

Lines changed: 39 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,39 @@
1+
# Kubernetes Integration
2+
3+
This guide explains how to use `async-container` with Kubernetes to manage your application as a containerized service.
4+
5+
## Deployment Configuration
6+
7+
Create a deployment configuration file for your application:
8+
9+
```yaml
10+
# my-app-deployment.yaml
11+
apiVersion: apps/v1
12+
kind: Deployment
13+
metadata:
14+
name: my-app
15+
spec:
16+
replicas: 1
17+
selector:
18+
matchLabels:
19+
app: my-app
20+
template:
21+
metadata:
22+
labels:
23+
app: my-app
24+
spec:
25+
containers:
26+
- name: my-app
27+
image: my-app-image:latest
28+
env:
29+
- name: NOTIFY_LOG
30+
value: "/tmp/notify.log"
31+
ports:
32+
- containerPort: 3000
33+
readinessProbe:
34+
exec:
35+
command: ["bundle", "exec", "bake", "async:container:notify:log:ready?"]
36+
initialDelaySeconds: 5
37+
periodSeconds: 5
38+
failureThreshold: 12
39+
```

context/systemd-integration.md

Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,22 @@
1+
# Systemd Integration
2+
3+
This guide explains how to use `async-container` with systemd to manage your application as a service.
4+
5+
## Service File
6+
7+
Install a template file into `/etc/systemd/system/`:
8+
9+
```
10+
# my-daemon.service
11+
[Unit]
12+
Description=My Daemon
13+
14+
[Service]
15+
Type=notify
16+
ExecStart=bundle exec my-daemon
17+
18+
[Install]
19+
WantedBy=multi-user.target
20+
```
21+
22+
Ensure `Type=notify` is set, so that the service can notify systemd when it is ready.

lib/async/container/version.rb

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -5,6 +5,6 @@
55

66
module Async
77
module Container
8-
VERSION = "0.27.5"
8+
VERSION = "0.27.6"
99
end
1010
end

0 commit comments

Comments
 (0)