You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Raise RecursionError if nurseries are too nested #3289
We should pretend that the call stack a nursery is in is added to any child tasks. While this is somewhat flimsy (we will only be able to check the call stack size when creating a new nursery), it will prevent some simple issues w/r/t recursion.
Makes sense, recursion limit should apply. Only occurring with nurseries isn’t too problematic, since if that doesn’t happen it’ll just occur with the normal limits. Though this issue applies to asyncio, maybe also regular generators. Might be worth raising in CPython itself. Especially since the actual recursion amount is all private, we’d have to create our own unrelated limit just for nurseries.
I was just thinking of, when a new nursery is made:
get call stack size (because the task is floating)
add the parent nursery's call stack size
save it as an attribute
check if it's larger than sys.getrecursionlimit()
So there's no internal CPython state to worry about. One thing that would be really nice is a way to add junk frames to the call stack cheaply so this can interop with CPython's normal recursive check.
I agree we can probably propose this as an improvement for asyncio.TaskGroup too.
Well the problem is I don’t think the stack size is publicly available, aside from iterating frames. The junk frames thing is what I was thinking, except just altering the stack size counter itself.
Yeah I was thinking to just iterate the call stack -- we already do that for KI protection. (Does that include frames for context managers and is therefore not accurate? If so then we might actually need some CPython changes...)
Activity
TeamSpen210 commentedon Jun 17, 2025
Makes sense, recursion limit should apply. Only occurring with nurseries isn’t too problematic, since if that doesn’t happen it’ll just occur with the normal limits. Though this issue applies to asyncio, maybe also regular generators. Might be worth raising in CPython itself. Especially since the actual recursion amount is all private, we’d have to create our own unrelated limit just for nurseries.
A5rocks commentedon Jun 17, 2025
I was just thinking of, when a new nursery is made:
sys.getrecursionlimit()So there's no internal CPython state to worry about. One thing that would be really nice is a way to add junk frames to the call stack cheaply so this can interop with CPython's normal recursive check.
I agree we can probably propose this as an improvement for
asyncio.TaskGrouptoo.TeamSpen210 commentedon Jun 17, 2025
Well the problem is I don’t think the stack size is publicly available, aside from iterating frames. The junk frames thing is what I was thinking, except just altering the stack size counter itself.
A5rocks commentedon Jun 17, 2025
Yeah I was thinking to just iterate the call stack -- we already do that for KI protection. (Does that include frames for context managers and is therefore not accurate? If so then we might actually need some CPython changes...)