Use the existing runloop for sync calls in async handler

[Kludex]

Originally opened by @bennovakovic on 2019-07-31 10:37:10 in encode/httpx

Hi, this library looks awesome and I really want to use it; but I seem to have hit a blocker and can't seem to find a solution in the docs.

TL;DR: Is there any way to provide our own runloop when using the sync calls as looking through the source the sync calls are actually using the async request call.

Basically I'm writing a client api that provides 2 interfaces; an async and sync interface.

The issue that i am having is that if I try to use the sync methods with an existing runloop (provided by Sanic in this scenario), it complains with the exception: Cannot run the event loop while another loop is running.

Essentially I'm just calling:

import httpx
...
class SomeClass(object):
    def get_some_url(self):
        r = httpx.get('some url')

note that nothing here is async; apart from the fact that the .get_some_url call is made from within an async function like so:

import SomeClass

async def handler(request):
    o = SomeClass()
    o.get_some_url()

---

This works fine when using the async calls like this:

import httpx
...
class SomeClass(object):
    async def get_some_url(self):
        client = httpx.AsyncClient()
        r = await client.get('some url')

import SomeClass

async def handler(request):
    o = SomeClass()
    await o.get_some_url()

So I was just wondering if its possible to provide our own runloop when using the sync calls? Sanic uses uvloop internally, would be nice to be able to just pass that straight in somehow when constructing the httpx object, or setting it as a property after import.

Thanks!

[Kludex]

Originally posted by @bennovakovic on 2019-07-31T10:45:12Z

FWIW; I tried the following in a vein hope that it would do what I wanted:

import httpx
client = httpx.Client(backend=<my app uvloop>)

But alas, no success.. this the end of the stacktrace.

   self.client = httpx.Client(backend=kwargs.get('runloop'))
  File "/usr/local/lib/python3.6/site-packages/httpx/client.py", line 85, in __init__
    backend=backend,
  File "/usr/local/lib/python3.6/site-packages/httpx/dispatch/connection_pool.py", line 97, in __init__
    self.max_connections = self.backend.get_semaphore(pool_limits)
AttributeError: 'Loop' object has no attribute 'get_semaphore'

[Kludex]

Originally posted by @bennovakovic on 2019-07-31T10:52:13Z

In the meantime; I'll just use requests for the sync stuff, it feels odd passing in a runloop when I'm doing sync calls; purely because internally you're using async under the hood even for sync requests, or am I mistaken? https://github.com/encode/httpx/blob/66754ad0c58d61d34489294530351aa4b17e217f/httpx/client.py#L625

[Kludex]

Originally posted by @cansarigol on 2019-07-31T11:04:13Z

FWIW; I tried the following in a vein hope that it would do what I wanted:

import httpx
client = httpx.Client(backend=<my app uvloop>)

But alas, no success.. this the end of the stacktrace.

   self.client = httpx.Client(backend=kwargs.get('runloop'))
  File "/usr/local/lib/python3.6/site-packages/httpx/client.py", line 85, in __init__
    backend=backend,
  File "/usr/local/lib/python3.6/site-packages/httpx/dispatch/connection_pool.py", line 97, in __init__
    self.max_connections = self.backend.get_semaphore(pool_limits)
AttributeError: 'Loop' object has no attribute 'get_semaphore'

Hi to use backend parameter, it has to be derived by ConcurrencyBackend.

[Kludex]

Originally posted by @bennovakovic on 2019-07-31T11:05:38Z

Yeah, I figured that after I got the exception. I figured it would handle a standard runloop.

[Kludex]

Originally posted by @cansarigol on 2019-07-31T11:06:04Z

you can check sample class from https://github.com/encode/httpx/blob/66754ad0c58d61d34489294530351aa4b17e217f/tests/dispatch/utils.py#L19

[Kludex]

Originally posted by @bennovakovic on 2019-07-31T11:07:34Z

Yeah, unfortunately I can't modify my existing runloop to meet the requirements of the backend parameter; it is given to me by sanic directly.

[Kludex]

Originally posted by @cansarigol on 2019-07-31T11:12:25Z

Maybe runloop would be added with a loop params rather backend. I'd want to :)

[Kludex]

Originally posted by @yeraydiazdiaz on 2019-07-31T11:13:28Z

There is no API to provide the event loop yourself, however there is a loop property in the AsyncioConcurrencyBackend that checks an existing private _loop instance variable you can potentially set to the Sanic event loop.

We should consider adding this as a feature though.

[Kludex]

Originally posted by @yeraydiazdiaz on 2019-07-31T11:20:53Z

I'm not sure about the context you're working with but there's some subtleties around using a the sync API in an async application.

The sync API internally uses the loop's run_in_executor which will create a ThreadPoolExecutor and run your request there which might hinder performance or just be unnecessary. If possible I'd suggest stayin in async land and use the AsyncClient, but, again, it depends on your context.

[Kludex]

Originally posted by @tomchristie on 2019-07-31T14:00:27Z

The issue that i am having is that if I try to use the sync methods with an existing runloop (provided by Sanic in this scenario), it complains with the exception: Cannot run the event loop while another loop is running.

Okay, that's a problematic thing to be doing.

If you're running in the context of an event loop, but then making blocking style network calls you're going to block the event loop. You don't want to be doing that.

We've got a relevant issue here about how we describe that most clearly in any raised exception, but it's a fundamental property of the differing concurrency model, rather than a bug (at least as I read it here)

[Kludex]

Originally posted by @tomchristie on 2019-07-31T14:02:13Z

I'd also echo what @yeraydiazdiaz's comment: if you're running in an async context, then you need to be using the async client.

(Tho it might be useful to understand why you're not doing that, in order to provide better support for other users who try the same thing)

[Kludex]

Originally posted by @bennovakovic on 2019-07-31T22:52:34Z

@yeraydiazdiaz Yeah I figured; I was just trying to make the api client library idiot proof; and also give them the option to use a sync client even in an async application (for whatever reason that might be). I totally agree; staying in async land is definitely where I want to be too; but I can't assume that everyone is in async land; in fact my experience is that most aren't in the python world, unfortunately.

[Kludex]

Originally posted by @bennovakovic on 2019-07-31T22:56:30Z

@tomchristie yeah I completely agree & understand; it was more a question of is it possible rather than what am I doing wrong. I understand how its working; but was seeing if the library could behave the way I was hoping based on the way I'm building out the api client library. No big deal though; I can just revert to the requests library for the sync client, and httpx for the async.
FWIW; this is how the user would create an instance of the client library:

client = MyApiClient.create('v1.async', apikey='foo')
# or 
client = MyApiClient.create('v1.', apikey='foo')

Then any following calls would either need to be using await if its the async api version, or just regular method calls in the sync scenario.

[Kludex]

Originally posted by @tomchristie on 2019-08-01T08:11:41Z

No big deal though; I can just revert to the requests library for the sync client, and httpx for the async.

That's not really the right resolution here.

httpx provides a sync client, for sync usage, and an async client, for async usage, so you have both cases covered.

The error you're seeing only occurs when you try to call into the sync interface from within an async context which a broken thing to do for your users, regardless of if that's implemented in requests, httpx or whatever. (*)

There are technical ways we could make it not error in httpx and carry on regardless, but it's far more sensible that we error loudly. I think it'd be worth us wrapping the Cannot run the event loop while another loop is running exception in our own exception class so that we can point to a relevant part in the async documentation explaining why that's not a valid thing to do.

(*) Unless you're switching over to sync portions of the codebase within a seperate thread, in which case httpx wouldn't raise the error you're seeing.

[Kludex]

Originally posted by @tomchristie on 2019-08-01T08:14:04Z

I was just trying to make the api client library idiot proof; and also give them the option to use a sync client even in an async application (for whatever reason that might be)

I guess this is the core bit. Making the library robust here ought to mean raising a nice clean, explanatory error when it's used in a broken way, rather than allowing that to pass silently.