Drop background manager (in favour of a two-function fork primitive).

[lovelydinosaur]

I think we're running against the grain with our current read, write, background_manager API on the backends.

Switching to the same style as the hip project is using for its concurrency backends is likely a smart thing for us to do here... https://github.com/python-trio/hip/tree/master/src/urllib3/_backends

What would it take for us to switch over to a send_and_receive_for_a_while API?

@florimondmanca - I seem to remember you did some work on scoping this out at some point?

[florimondmanca]

@tomchristie I believe I had a working implementation of this in #526, though not really as a « read and write for a while » method.

[florimondmanca]

But I remember we said somewhere that the parallel send request/receive response flow may not actually be necessary - what’s the latest status on that?

[lovelydinosaur]

Yeah I dug back into that... and no, it's not neccessary for HTTP/1.1.
I was forgetting tho that it is absolutely neccessary for HTTP/2.

(I tried dropping background manager out everywhere to help figure out if we had any obvious failures once we did that, and an HTTP/2 "send a large request" test case started failing, which retrospectively I should have realised would occur.)

[lovelydinosaur]

Part of the motivation here is that if we fall into line with how hip have tackled it, we can draw from their work on twisted, sync, and anyio backends.

(Now that we've dropped out all the sync-bridging code, there's a much clearer path onto how we'd ought to be supporting the sync case.)

[lovelydinosaur]

As it happens I'm probably fairly agnostic on the benefits of read+write+background manager vs. read_and_write_for_a_while, but I think we're probably better of following their lead here, than not, simply for the benefits of all singing from the same song-sheet, right?

[florimondmanca]

Yeah, I’m good either way. #526 taught be that this won’t necessarily result in simpler code, though — bit of the opposite, since we have to provide some extra abstraction to deal with HTTP/1.1 vs HTTP/2. There may be extra simplifications made possible since we dropped sync. But yeah I’d be fine with taking the same approach than hip here. :)

[lovelydinosaur]

Right.

Also the big advantage with this is that a SyncBackend with read_and_write_for_a_while makes sense, but a SyncBackend with read+write+background manager isn't really possible. (At least without introducing multi-threading, which we clearly wouldn't want.)

That didn't matter to us when our approach was "sync can bridge onto the async variant", but it does matter to us now.

[pquentin]

simply for the benefits of all singing from the same song-sheet

That makes a lot of sense and I would also be happy to follow the lead of httpx for any part of hip that is unnecessarily different from httpx. 👍

[lovelydinosaur]

Actually there's a neat alternative for us here...

The background manager API is actually a bit grungy, because although it nearly fits trio's structured concurrency model, it doesn't entirely, since we're calling directly into Trio's nursery __aenter__ and __aexit__, which I'd expect the trio team would consider at the least a code-smell.

We only ever want to support "branch two flows of execution", so our backends could instead use an API of...

• read
• write
• fork((func1, *args, **kwargs), (func2, *args, **kwargs))

Instead of...

• write
• read_and_write_for_a_while

Our SyncBackend (when it comes) wouldn't be able to support fork, but that's ok. We only need read and write for h11 support, and don't have to offer h2 support for sync.

Our AsyncBackends would probably be slightly cleaner, since read_and_write_for_a_while is a bit of an awkward operation. Also our resulting code HTTP handling code would probably be nicer too, because forking two flows of control is a nice sequential flow, vs. read_and_write_for_a_while's callbacks, which are more awkard.

None of that is to say that we couldn't later switch to the alternate if needed, but this looks to me like the simplest possible route, while also still properly fitting in to the structured concurrency model, unlike our existing case, which is nearly there, but has a slight kludge to it.

[lovelydinosaur]

Specifically, our semantics for the fork primitive would be...

• start func1, start func2.
• wait for func1, if it raises an exception raise it (cancelling and ignoring func2).
• wait for func2, if it raises an exception raise it.

We don't need to care about multi-exception cases, and should just raise the first of any exception we see.