Thomas Grainger

@agronholm I think this is a bug in Trio too - it's just convenient that trio tasks happen not to be allocated in the same location

I think anyio should maintain its own counter of tasks and use a WeakKeyDictionary to lookup tasks in and return that count eg: https://github.com/python-trio/trio/blob/6754c74eacfad9cc5c92d5c24727a2f3b620624e/trio/_core/_run.py#L1071

Anyio would need to maintain a WeakKeyDictionary from the concrete task object to a TaskInfo

number of TaskInfo objects created, eg: ```python @dataclass class TaskInfo: ... id = field(default_factory=itertools.count().__next__, init=False) ```

well they're not currently in sequence, they're just the whim of the allocator

anyio task ids would be in sequence if TaskInfo objects are created eagerly when the _task_state entry is created.

> Alright. Then, finally, could there be a situation where an underlying Task could be assigned two artificial IDs through two TaskInfo objects, perhaps when the first TaskInfo has been...

> Anyio would need to maintain a WeakKeyDictionary from the concrete task object to a TaskInfo

something like this? ```python _task_infos = WeakKeyDictionary[object, TaskInfo] _counter = itertools.count() class TaskInfo: def __init__(self, task): self.id = next(_counter) ti = get_async_lib().extract_task_info(task) self.parent_id = ti.parent_id self.coro = ti.coro def get_current_task_token():...

and here's a PR to make ParkingLot slotted: https://github.com/python-trio/trio/pull/1971