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

Remove nest-asyncio dependency #835

Merged
merged 53 commits into from
Oct 6, 2022

Conversation

blink1073
Copy link
Contributor

@blink1073 blink1073 commented Sep 14, 2022

  • Remove the need for nest_asyncio by only calling asynchronous methods on self from within an asynchronous method and using the task runner method described in Clean up synchronous managers #755

  • The blocking channel/client/manager methods call run_sync to run ad-hoc and background loop(s) as needed, and use zmq.Context. The async channel/client/manager use async/await and zmq.asyncio.Context.

  • For session objects, we make all of the methods synchronous and check for futures returned by socket methods, converting them to values as needed. We had to subclass ZMQStream to do the same, but perhaps this logic should go in pyzmq itself.

  • Add tests for async and threaded clients

@blink1073 blink1073 added this to the 8.0 milestone Sep 14, 2022
@davidbrochart
Copy link
Member

Looks like you're having fun in there 😄

@blink1073
Copy link
Contributor Author

Looks like you're having fun in there 😄

Ha, yes and no.

@blink1073
Copy link
Contributor Author

I think we introduced a failure:

Error: TestKernelManager.test_ipc_cinfo

AttributeError: Context has no such option: _SOCKET_TYPE

try:
orig_socket = socket
socket = f(self, *args, **kwargs)
orig_socket.close()
Copy link
Member

Choose a reason for hiding this comment

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

Why is orig_socket created and closed, instead of removed entirely?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Didn't we need to create it to determine it's type?

Copy link
Member

Choose a reason for hiding this comment

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

No, we only check self.context._socket_class which we can do before creating sockets

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay, I removed the throwaway socket

@@ -807,6 +807,10 @@ def send(
# ZMQStreams and dummy sockets do not support tracking.
track = False

if isinstance(stream, zmq.asyncio.Socket):
assert stream is not None
stream = zmq.Socket.shadow(stream.underlying)
Copy link
Member

Choose a reason for hiding this comment

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

👍

@@ -807,6 +807,10 @@ def send(
# ZMQStreams and dummy sockets do not support tracking.
track = False

if isinstance(stream, zmq.asyncio.Socket):
assert stream is not None
Copy link
Member

Choose a reason for hiding this comment

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

I assume leftover debug, this will never be None if it's an asyncio.Socket

Suggested change
assert stream is not None

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is there to satisfy mypy

Copy link
Member

Choose a reason for hiding this comment

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

type checkers, always making code better!

@minrk
Copy link
Member

minrk commented Sep 27, 2022

zeromq/pyzmq#1785 introduces support in ZMQStream for both asyncio sockets (by immediately shadowing them to sync sockets) and allowing coroutines in on_recv callbacks.

It also makes it easier to explicitly create a particular socket class per ctx.socket call with e.g. ctx.socket(zmq.PUSH, socket_class=zmq.asyncio.Socket)

@@ -191,7 +192,7 @@ async def test_async_restart_check(config, install_kernel, debug_logging):
km = AsyncIOLoopKernelManager(kernel_name=install_kernel, config=config)

cbs = 0
restarts = [asyncio.Future() for i in range(N_restarts)]
restarts = [asyncio.futures.Future() for i in range(N_restarts)]
Copy link
Member

Choose a reason for hiding this comment

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

This should still be asyncio.Future. That's the correct, public name for this. asyncio.futures is an implementation detail, which can change.

Copy link
Member

Choose a reason for hiding this comment

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

...unless these are meant to now be concurrent.futures.Futures? concurrent futures are also awaitable with await asyncio.wrap_future(concurrent_future)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We needed to use concurrent futures in the non-async tests, and asyncio futures in the async ones, I'll update to use asyncio.Future

@blink1073 blink1073 marked this pull request as ready for review October 6, 2022 20:32
@blink1073
Copy link
Contributor Author

Downstream errors are addressed, I'm going to merge and iterate.

@blink1073 blink1073 merged commit 5874148 into jupyter:main Oct 6, 2022
@blink1073 blink1073 deleted the synchronous_managers branch October 6, 2022 20:33
impact27 added a commit to impact27/jupyter_client that referenced this pull request Dec 3, 2022
I know that this is already obsolete with jupyter#835. 
Sometimes, this loop is not marked by nest_asyncio (when calling `run_sync`) so this makes sure that the two eventloops (`asyncio.new_event_loop()` and the other created in `ioloop.IOLoop()`) do not make the system crash.
Unfortunately, I can not really give you a reproducible example as I was messing with spyder code when it happened. Feel free to close this PR if you think this is not needed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants