xiio, branch HEADreally simple async runtimefeefa7d576feb55762f29663aef8e7d81d2243ae2026-04-25T11:44:14Z2026-04-25T11:48:38Zbump minimum python version to 3.11Tobias Bengforttobias.bengfort@posteo.debump minimum python version to 3.11
asyncio.timeout() is not available before that
5750a828cfb92a889a672e3e018ce4c0f1a719b12026-04-25T11:35:24Z2026-04-25T11:48:29Zci: fix python versionTobias Bengforttobias.bengfort@posteo.deci: fix python version
c6b5d2af9309c2bb20c737d7bf2e164d23f56de32026-04-18T18:59:08Z2026-04-22T17:46:27Zavoid context switch in thread poolTobias Bengforttobias.bengfort@posteo.deavoid context switch in thread pool
d0bc4771606dc88db648aaa06bd70d87c8929a842026-04-16T20:37:03Z2026-04-22T17:46:12ZTaskGroup: refactorTobias Bengforttobias.bengfort@posteo.deTaskGroup: refactor
also removes one cancellation point
b34bac8ed1f750b2fb8db0a0358826d0593a7b902026-04-16T17:16:49Z2026-04-22T17:46:12Zadd ThreadPool and in_thread()Tobias Bengforttobias.bengfort@posteo.deadd ThreadPool and in_thread()
5b257c932b01485db2170c21116f5ef06754b76b2026-04-12T17:29:25Z2026-04-17T20:19:02Zreduce test timing precisionTobias Bengforttobias.bengfort@posteo.dereduce test timing precision
c383ca69e8b62de8bd033d2b664192d7a70ea35e2026-04-11T06:56:45Z2026-04-17T20:19:02Zadd on_asyncio() compat functionTobias Bengforttobias.bengfort@posteo.deadd on_asyncio() compat function
d241b8a53cab1f54563072f953803756c32cbf022026-04-12T16:45:47Z2026-04-17T20:19:02Zadd subscribe_signals()Tobias Bengforttobias.bengfort@posteo.deadd subscribe_signals()
37911ea6ed293cd987fad904b07ab4b0278576042026-04-12T13:36:32Z2026-04-17T20:19:02Zadd run_process()Tobias Bengforttobias.bengfort@posteo.deadd run_process()
Mostly the same interface as `subprocess.run()` from the standard
library, just async.
Uses a pidfd to integrate into the event loop, so it is linux-specific.
https://docs.python.org/3/library/subprocess.html
https://docs.python.org/3/library/asyncio-subprocess.html
https://trio.readthedocs.io/en/stable/reference-io.html#trio.Process
e8447dd8daf816df9be346b112c65e57e538fcd52026-04-12T17:21:24Z2026-04-17T20:19:02Zrefactor: split into multiple filesTobias Bengforttobias.bengfort@posteo.derefactor: split into multiple files
782851e16a4988987e94d22388efb84d2ab988ac2026-02-27T00:46:27Z2026-04-17T20:19:02Zadd timeout()Tobias Bengforttobias.bengfort@posteo.deadd timeout()
Just a higher level abstraction on top of TaskGroup.
0df8fb90d90a5f881d9815ac411c82c769ee5a002026-02-27T15:55:03Z2026-04-17T20:19:02Zturn TaskGroup into a context managerTobias Bengforttobias.bengfort@posteo.deturn TaskGroup into a context manager
This is wild and I am honestly not 100% sold that this is worth it.
Feature-wise, the main difference from the previous version is that the
subtasks already start executing before the inner block is done.
A similar thing was already possible before by using an additional
function:
```python
async def foo(tg):
tg.add_task(sleep(1))
sleep(1)
tg = TaskGroup()
tg.add_task(foo(tg))
await tg
```
But I must admit that the context manager syntax is nicer:
```python
async with TaskGroup() as tg:
tg.add_task(sleep(1))
sleep(1)
```
Unfortunately, the implementation is a real mind bender:
When we enter the TaskGroup, we want to wrap the parent task. In order
to do that, we first need to get a reference to it. The way we do that
is a bit hacky: We usually use the async/await syntax to pass conditions
and available files back and forth between the coroutines and our
plumbing. Now we abuse the same system to pass a task into the
coroutine.
Now we put the generator of the coroutine that is currently running in a
new task and add it to the TaskGroup. The parent task instead receives
the generator of the `wrapper()` coroutine.
The next time we await, a condition will be yielded to the parent task,
which now references a completely different generator. In addition, the
task that now wraps this coroutine will never receive the condition.
Fortunately, there is a simple fix: We can await
`Condition(time=-math.inf)` in both coroutines to make everything line
up.
After that switcharoo is done, we can `await self` to wait for the
TaskGroup to complete. As part of that, we will at some point exit the
TaskGroup. At that point we abuse the async/await syntax a second time
to raise an exception, which will finish the task without stopping the
generator.
Once the TaskGroup has finished executing, we can attach the generator
back to the parent task and yield control back to it. It will resume
execution of its original generator inside `__aexit__()`. `wrapper()` is
not referenced anywhere anymore, so it will be garbage collected.
d3f5e579b6fc9897910ec87023a14366b298faad2026-02-26T22:33:19Z2026-04-17T20:19:02Zadd TaskGroupTobias Bengforttobias.bengfort@posteo.deadd TaskGroup
a more general multiplexing primitive that allows to add tasks after it
has already started.
919c743e81d34b2eba2473c60d5026d3290d06792026-02-26T23:31:48Z2026-04-17T20:19:02Ztest read/writeTobias Bengforttobias.bengfort@posteo.detest read/write
5395e355f1325dd1a5a621148a18020615e612e62026-02-26T22:55:29Z2026-04-17T20:19:02Zadd READMETobias Bengforttobias.bengfort@posteo.deadd README
47d701f6d787451e3cbb15c5ef1f6dd28ffb617e2026-02-26T22:15:54Z2026-04-17T20:19:02Zadd gather() for multiplexingTobias Bengforttobias.bengfort@posteo.deadd gather() for multiplexing
2ca58a870010e789abb171a8cba9f0547fa1d9202026-02-26T21:31:55Z2026-04-17T20:18:58Zallow to combine and check conditionsTobias Bengforttobias.bengfort@posteo.deallow to combine and check conditions
We can not multiplex over multiple coroutines yet. To do that, we have
to wait for a combined condition from multiple coroutines, and then
decide which condition is fulfilled so we know which coroutine to
resume. So here we are building the necessary infrastructure.
3261d16114cc24b5d12975c008a3a87cf7f98b7c2026-02-26T21:25:04Z2026-04-16T17:34:38Zadd type annotationsTobias Bengforttobias.bengfort@posteo.deadd type annotations
fc000f4a6a23c0aa964652959f2296015a985d762026-02-26T22:16:41Z2026-04-16T17:33:49Zadd futuresTobias Bengforttobias.bengfort@posteo.deadd futures
If multiple coroutines are waiting for a message on the same socket, it
can be helpful to have a mechanism to wake up the right one. Futures are
a pure python abstraction that does exactly that.
62f05c12a608b69bda7bb5eff30a0be859df96a42026-02-26T18:42:02Z2026-04-16T17:33:25Zadd support for reading/writing filesTobias Bengforttobias.bengfort@posteo.deadd support for reading/writing files
So far we can wait for timeouts. In a real system, we also want to be
able to wait for files. So we replace the `Timeout` class by a more
generic `Condition` class together with the `sleep()`, `read()` and
`write()` helpers. We use the `selectors` module to wait for files to
become available.
8ed7defd595a8e895c90830093d01959b19a03cc2026-02-26T18:37:21Z2026-02-27T00:22:09Zasync/await syntaxTobias Bengforttobias.bengfort@posteo.deasync/await syntax
This is just an abstraction on top of generators. Our function is now
called a *coroutine*.
d39fb2b7a1d88a6447fe62d7206fea21e836dabe2026-02-26T18:34:19Z2026-02-27T00:22:06Zallow to pause executionTobias Bengforttobias.bengfort@posteo.deallow to pause execution
The first step is to move the blocking call out of the function. To do
that, we pause execution by using the `yield` keyword. This turns our
function into a generator function. The separate `run()` function will
do the blocking call and resume the generator function once that is
done. The special `StopIteration` exception is raised when the generator
function returns.
6b9965a49151195a363b7eb06f53a6379e1102ea2026-02-27T00:04:20Z2026-02-27T00:08:14Zsimple sync test functionsTobias Bengforttobias.bengfort@posteo.desimple sync test functions