Skip to content

Conversation

blueyed
Copy link
Contributor

@blueyed blueyed commented May 6, 2019

This allows for overriding it easily in derived classes, and it seems to
be better than changing the loop's default executor (in the case of
ASGI_THREADS being set).

Ref: django/channels#1091

Copy link

@auvipy auvipy left a comment

Choose a reason for hiding this comment

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

Please fix the lint errors :D

@blueyed
Copy link
Contributor Author

blueyed commented May 6, 2019

Needs test adjustments (where the old method of changing the default executor is used).

Copy link
Member

@carltongibson carltongibson left a comment

Choose a reason for hiding this comment

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

Hey @blueyed. This seems reasonable(, if you're awaiting some kind of input before updating the tests.)

@blueyed
Copy link
Contributor Author

blueyed commented May 7, 2019

Adjusted the test.
Let's wait for django/channels#1290 on this though.
It is not really needed for it currently, but might be good in general - although I think it could/should be done in the constructor probably instead.

@blueyed blueyed force-pushed the executor branch 2 times, most recently from f26a9a3 to 667b48f Compare September 11, 2019 11:37
@blueyed
Copy link
Contributor Author

blueyed commented Sep 11, 2019

Rebased.

This allows for overriding it easily in derived classes, and it seems to
be better than changing the loop's default executor (in the case of
ASGI_THREADS being set).

Ref: django/channels#1091
@blueyed

This comment has been minimized.

monkeypatch.setenv("ASGI_THREADS", 99)
orig_executor = async_function.executor
async_function = sync_to_async(sync_function)
assert async_function.executor is orig_executor
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure about this though: it might actually make sense to use a separate executor for every decorator?
This could also be achieved through a new kwarg.

@blueyed blueyed changed the title SyncToAsync: use executor attribute [WIP/RFC] SyncToAsync: use executor attribute Sep 11, 2019
@HMaker
Copy link

HMaker commented Jan 16, 2021

how is this PR going?

@andrewgodwin
Copy link
Member

The PR is still marked as WIP so I'm going to close it to now as it's been over a year with no response from the author.

@blueyed blueyed changed the title [WIP/RFC] SyncToAsync: use executor attribute SyncToAsync: use executor attribute Jan 17, 2021
@blueyed blueyed changed the title SyncToAsync: use executor attribute [RFC] SyncToAsync: use executor attribute Jan 17, 2021
@blueyed
Copy link
Contributor Author

blueyed commented Jan 17, 2021

Removed the (outdated) WIP label.
IIRC it should be good, but there was/is an open question still.
I'm fine with leaving it closed (cannot re-open anyway), just wanted to let you know.

@blueyed blueyed deleted the executor branch January 17, 2021 22:01
@blueyed blueyed restored the executor branch January 17, 2021 22:01
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 this pull request may close these issues.

5 participants