Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Move Config#load out of Server#serve to enable Eager Asynchronous Construction of App #942

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

Move Config#load out of Server#serve to enable Eager Asynchronous Construction of App #942

wants to merge 1 commit into from

Conversation

MarioIshac
Copy link

@MarioIshac MarioIshac commented Jan 22, 2021 •
edited
Loading

Fixes #941 by identifying the 3 call sites (test utility, gunicorn worker, uvicorn runner itself) Server#serve is used at and moving Config#load to those sites.

@florimondmanca florimondmanca mentioned this pull request Jan 22, 2021
Open
@florimondmanca
Copy link
Member

florimondmanca commented Jan 22, 2021 •
edited
Loading

@MarioIshac Thanks for this PR. I think this makes sense, but just need a bit of careful thinking.

How does this behave with Uvicorn multiprocessing? Eg --workers 3, and --reload? Do we need to change anything else there?

Edit: okay, answering my own question, it seems we're all good. Here's how we spawn for each case (normal, reload, multiple workers):

uvicorn/uvicorn/main.py

Lines 377 to 386 in c6b80fc

if config.should_reload:
sock = config.bind_socket()
supervisor = ChangeReload(config, target=server.run, sockets=[sock])
supervisor.run()
elif config.workers > 1:
sock = config.bind_socket()
supervisor = Multiprocess(config, target=server.run, sockets=[sock])
supervisor.run()
else:
server.run()

In each case we target server.run(), so the scope of when we call config.load() just gets moved from server.serve() to server.run().

@MarioIshac
Copy link
Author

MarioIshac commented Jan 22, 2021 •
edited
Loading

@florimondmanca I'll recheck the interaction between this PR and uvicorn multiprocessing to make sure I didn't miss anything. I also will take a look at how this PR behaves with apps imported as the object itself (uvicorn.run(main.app) instead of by name (uvicorn.run("main:app")), since after our discussion I realized that this might affect the PR. I've got to go to work in a bit, but I'll have an update later today.

florimondmanca
florimondmanca reviewed Jan 22, 2021
View reviewed changes
Copy link
Member

@florimondmanca florimondmanca left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is looking good.

@euri10, any opinion by chance?

@MarioIshac Would it be possible to add a test for this, eg by passing an app factory (see associated existing tests) that runs something on the event loop?

uvicorn/server.py
Comment on lines +47 to +51
config = self.config
config.setup_event_loop()

if not config.loaded:
config.load()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's add a comment about why we're doing this here, perhaps?

Suggested change
config = self.config
config.setup_event_loop()
if not config.loaded:
config.load()
# Setup and load app before entering the async environment, so it's possible to
# run any async setup on our side or in the app module.
# See: https://github.com/encode/uvicorn/issues/941
config = self.config
config.setup_event_loop()
if not config.loaded:
config.load()

@euri10
Copy link
Member

euri10 commented Jan 23, 2021

I think this is looking good.

@euri10, any opinion by chance?

@MarioIshac Would it be possible to add a test for this, eg by passing an app factory (see associated existing tests) that runs something on the event loop?

yep, a test for that is a good idea

@MarioIshac
Copy link
Author

I am working on writing the test, but it looks like @pytest.mark.asyncio already runs the test function in its event loop, so constructing the app within the test function will fail there. But some test functions (such as within test_lifespan.py) are managing the event loop themselves, so I'll see if I can do something like that.

@MarioIshac MarioIshac marked this pull request as draft January 29, 2021 21:51
@euri10
Copy link
Member

euri10 commented Jun 7, 2021 •
edited
Loading

I have kind of the feeling this could be resurrected for 3.10

@graingert
Copy link
Member

@euri10 I don't think this makes sense anymore, given asyncio.get_event_loop().run_until_complete(...) is no longer supported in python3.10+

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@florimondmanca florimondmanca florimondmanca left review comments

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Eager Asynchronous Construction of App Interferes with Running Event Loop
4 participants
@MarioIshac @florimondmanca @euri10 @graingert