ross
commented
6 years ago Interesting question. Thinking about it for a bit i believe the best bet here would actually be to do the authentication request synchronously and just use the thread that was allocated to work on the original request which will already be in the background.
If you're doing lots of requests that may or may not need individual auth processes that should be fine, on the other hand if you're doing many async requests that would need to auth together, e.g. many calls to an API when your token expires, you'd probably need to do something more involved/advanced. It'd probably be out of scope for requests_futures to try and first-class support that pattern, but it would be a interesting one to solve. I think I'd probably separate the auth process into it's own thing and come up with a way to catch auth failures and just retry requests that didn't work due to auth problems. I don't think I'd try and auth individual requests when they need it since that would result in many authentication attempts in parallel.
aparamon
sammck
github-actions[bot]
It would be nice if one could pass an "auth" parameter to session.request that when called returns a Future, and have a way to suspend the request (possibly using fibers?) and freeing up the worker thread while waiting for authentication to complete. As it stands, the original worker thread stalls waiting for authentication, which itself might, in custom auth schemes, make use of the session to execute asynchronous requests. This could lead to deadlock if there are not enough worker threads.