-
-
Notifications
You must be signed in to change notification settings - Fork 754
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.
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
Unblock periodically the main process to check for signal #2059
Conversation
…r other subprocesses to join before finishing execution
if self.should_exit.wait(self.config.reload_delay): | ||
break |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a setting that should be used only for --reload
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh right, do you think it makes sense to add a config just for this? Or is it better to use a fixed timeout/constant value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't there an alternative solution? This problem started happening after a feature we added, didn't it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to remove the signal added in #1909 to check but the issue was still there on windows. I'll try to diff from 0.21.1 and isolate the features to find the exact change that caused the issue.
Side note: I also noticed also a flaky startup issue happening on windows while debugging this that I'll dig more on it later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, tests on reload are flaky... I don't know why. You can add the skipif
on them as well for the time being. I'll accept a PR for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just tested with 0.21.1
and the error of ctrl+c
is still there.
I'm running it on Windows 10 with powershell 7.3.6 but I also tested with cmd
and got the same freeze.
Python version used for the test is 3.11.1
and the packages are those:
➜ pip freeze
annotated-types==0.5.0
anyio==3.7.1
click==8.1.6
colorama==0.4.6
fastapi==0.100.0
h11==0.14.0
idna==3.4
pydantic==2.1.1
pydantic_core==2.4.0
sniffio==1.3.0
starlette==0.27.0
typing_extensions==4.7.1
uvicorn==0.21.1
Also, the app used for the test was the fastapi base example:
from typing import Union
from fastapi import FastAPI
app = FastAPI()
@app.get("/")
def read_root():
return {"Hello": "World"}
@app.get("/items/{item_id}")
def read_item(item_id: int, q: Union[str, None] = None):
return {"item_id": item_id, "q": q}
And the command I'm running is:
uvicorn main:app --workers 2
Closing this one since #2183 seems to solve the issue on windows |
Summary
This adds a periodic unblock of the main process to check for signals sent like SIGINT or SIGTERM.
In windows the main process does not listen to signals when blocked by the wait call.
Closes: #1972
Checklist