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.

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

0.14 overrides event loop choice and breaks tests #188

Closed
bryevdv opened this issue Sep 22, 2020 · 2 comments · Fixed by #192
Closed

0.14 overrides event loop choice and breaks tests #188

bryevdv opened this issue Sep 22, 2020 · 2 comments · Fixed by #192

Comments

@bryevdv
Copy link

bryevdv commented Sep 22, 2020

Bokeh relies on Tornado which is incompatible with the default Proactor event loop on Windows starting with Python 3.8.

Accordingly, we call this function

def fixup_windows_event_loop_policy() -> None:
    if sys.platform == 'win32' and sys.version_info[:3] >= (3, 8, 0):
        import asyncio
        if type(asyncio.get_event_loop_policy()) is asyncio.WindowsProactorEventLoopPolicy:
            # WindowsProactorEventLoopPolicy is not compatible with tornado 6
            # fallback to the pre-3.8 default of WindowsSelectorEventLoopPolicy
            asyncio.set_event_loop_policy(asyncio.WindowsSelectorEventLoopPolicy())

in any module that will need to use tornado. Since 0.14 became available, all our Tornado tests are failing, because the Proactor loop is being used in tests even despite our explicit event loop policy selection:


509
self = <ProactorEventLoop running=False closed=False debug=False>, fd = 2832
510
callback = <bound method BaseAsyncIOLoop._handle_events of <tornado.platform.asyncio.AsyncIOMainLoop object at 0x0000020E9CBDCB50>>
511
args = (2832, 1)

Is this intentional? is there some new way we should configure pytest-asyncio to be able to not override our policy selection?

ref: bokeh/bokeh#10514

@bryevdv bryevdv changed the title 0.14 overrides even loop choice and breaks tests 0.14 overrides event loop choice and breaks tests Sep 22, 2020
@seifertm
Copy link
Contributor

seifertm commented Oct 4, 2020

I believe this is a duplicate of #168
@bryevdv Can you check if this is the case and close this issue if applicable?

@bryevdv
Copy link
Author

bryevdv commented Oct 4, 2020

Closing/labeling is a function for maintainers (I don't have permissions to apply any"dupe" label, etc). In any case it seems plausible that that issue is a duplicate, though I am not 100% certain and also the discussion there seems to be veering towards offering explicit loop policy selection via a per-test fixture. That would not be a workable solution for us, we need the configured choice that the library itself makes be respected (as it should be, by default)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants