1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
|
features:
- |
Added a new `threading` backend to `oslo.service`, using standard Python
threads instead of `eventlet`. This includes a full implementation of:
- `Service`, `Launcher`, `ServiceLauncher`, and `ProcessLauncher` using
`cotyledon`
- `LoopingCall` variants (`FixedIntervalLoopingCall`,
`DynamicLoopingCall`, etc.) using `futurist.ThreadPoolExecutor`
- A new `ThreadGroup` and `Thread` abstraction to mimic `eventlet`-like
behavior
- A native `SignalHandler` implementation using standard Python signals
This backend provides a standard-thread-compatible alternative that avoids
monkey-patching, making it suitable for environments where `eventlet` is
problematic or undesirable.
Additionally:
- `ProcessLauncher` now supports a `no_fork=True` mode, allowing services
to run in the main process without forking. This is useful when `fork()`
is unsafe — for example, in threaded environments or with Python 3.12+
where the default multiprocessing start method has changed to `spawn`.
- A new `register_backend_default_hook()` API has been added. It allows
users to define a fallback backend type in case `init_backend()` was not
called early enough. This is helpful in environments where import order
or initialization timing cannot be guaranteed.
Example:
```python
from oslo_service import backend
backend.register_backend_default_hook(lambda: backend.BackendType.THREADING)
```
This hook will only be used if `init_backend()` has not already been called.
upgrade:
- |
While Python 3.14 defaults to ``spawn`` as the multiprocessing start
method, `oslo.service` continues to rely on ``fork`` as the only supported
method for creating worker processes. Many parts of OpenStack depend on
objects that cannot be safely pickled (e.g. argparse parsers, thread locks,
lambdas in config defaults), which makes ``spawn`` currently impractical.
In the long term, process scaling should be handled externally (e.g. via
Kubernetes or systemd), rather than by the service itself.
issues:
- |
When using the `threading` backend with multiple workers
(i.e. `ProcessLauncher` with `fork()`), **starting threads before the fork
occurs can lead to corrupted state** due to how `os.fork()` behaves in
multi-threaded processes. This is a known limitation in Python.
See: https://gibizer.github.io/posts/Eventlet-Removal-The-First-Threading-Bug/#threads--osfork--confused-threadpools
To avoid this issue, you can:
- Ensure that no threads are started before `oslo.service` forks the workers.
- Use `ProcessLauncher(no_fork=True)` to disable forking entirely.
- Explicitly manage thread lifecycle — for example, stop all threads before
forking, as currently done in Nova.
|
