The BackgroundManager is used in dispatchers/http11.py and dispatchers/http2.py to concurrently send the request and read the first part of the response. Its usage currently looks like this:
async with backend.background_manager(coro, ["arg1", arg2"]):
# Do stuff while background task is running
...
This is limited in that we cannot start more than one task easily. However, we will need this feature to generalize the usage of ConcurrencyBackend across the code base.
Here's a more flexible API, inspired by trio's nurseries:
async with backend.background_manager() as background:
background.start_soon(coro1, "arg1", "arg2")
# Do stuff while background task is running
Usage with multiple tasks:
async with backend.background_manager() as background:
background.start_soon(coro1, "arg1", "arg2")
background.start_soon(coro2, "arg3", "arg4")
# Do stuff while background tasks are running
Seems like a sensible tack yup.
One alternative that we could end up exploring at some point would be to use a different pattern style here. We're using the background manager in order to allow us to perform simultanous read/writes. The urllib3 async work instead uses a "read and write for a bit" primitive that backends need to implement.
I won't get into digging into that in detail here, but it's feasible that it could be a neater pattern to have our Socket interface expose a .read_and_write(...) method that different backends implement, rather than having to go all the way into exposing context blocked background managers.
That's almost certainly more work, since it'd mean rejigging the h2/h11 implementations a bit, but it's also more constrained than exposing full background managers as part of the concurrency interface. (Tho we've also got a related bit of work around the ASGI implementation, which'd need further thinking about.)
Actually, we're also going to need the background manager in ASGIDispatch, more specifically to run the app in the background as we're pushing content to the response.
Essentially, this:
loop = asyncio.get_event_loop()
app_task = loop.create_task(run_app())
# ...
async def on_close():
await app_task
would become:
background = await backend.background_manager(run_app).start() # alias to .__aenter__()
# ...
async def on_close():
await background.close() # alias to .__aexit__(None, None, None)
As visible here, thanks to the refactor getting rid of FIRST_COMPLETED, we can get away with BackgroundManager only handling a single coroutine — which means this issue has gone stale.
But regarding the .read_write() idea, it looks to me like we're going to need the BackgroundManager anyway. So perhaps it's best to leave usage of the background manager in h2/h11 as it is now?
I'll close this for now since the ability to run multiple background tasks isn't a requirement anymore. :-)
Most helpful comment
Seems like a sensible tack yup.
One alternative that we could end up exploring at some point would be to use a different pattern style here. We're using the background manager in order to allow us to perform simultanous read/writes. The urllib3 async work instead uses a "read and write for a bit" primitive that backends need to implement.
I won't get into digging into that in detail here, but it's feasible that it could be a neater pattern to have our Socket interface expose a
.read_and_write(...)method that different backends implement, rather than having to go all the way into exposing context blocked background managers.That's almost certainly more work, since it'd mean rejigging the h2/h11 implementations a bit, but it's also more constrained than exposing full background managers as part of the concurrency interface. (Tho we've also got a related bit of work around the ASGI implementation, which'd need further thinking about.)