Dear Darian, Thank you for your links, they were extremely useful for me!
I’ve investigated all of them and found that Xeus kernel already moved handling of the control channel to a separate thread. That works fine in Xeus, so I propose to move the control channel to a separate thread in ipykernel too. What do you think? Thanks, Vladimir On Monday, September 30, 2019 at 4:10:46 PM UTC+7, Afshin T. Darian wrote: > > Dear Vladimir, > > Thank you for writing about what you've been working! This is an exciting > area to think about and it's gratifying seeing movement on it. > > You are thinking along very similar lines to what other debugging efforts > in Jupyter have considered. The emerging consensus is: > > - Like you've discovered, the `comm` channel is not the most > appropriate channel for this activity, but indeed the messages for > debugging should happen on a ØMQ channel. The channel that current > debugging efforts have been using for this is the `control` channel. > - Because a standard has come out of Visual Studio Code's work on > this, adopting it increases the available ecosystem of both actual tools > we > could use and also just familiarity with the problem space: > https://microsoft.github.io/debug-adapter-protocol/ > - Here is the current state of affairs in supporting the Debug Adapter > Protocol on the `control` channel: > https://github.com/jupyter/jupyter_client/issues/446 > - Here is the initial conversation about implementing a front-end for > a debugger in JupyterLab: > https://github.com/jupyterlab/team-compass/issues/5 > - Here is a Python kernel, built by QuantStack, that has an initial > implementation of Python debugging: > https://github.com/QuantStack/xeus-python > - Here is work-in-progress JupyterLab extension that is not ready for > public consumption, but is targeting the JupyterLab 2.0 release to support > a first pass on debugging functionality: > https://github.com/jupyterlab/debugger/ > > I hope some of these efforts are helpful to your work, or even inspire you > to jump in and work on them. Some of the other folks who have been working > on these things may have more to add. > > Cheers! > > -Darian > > On Mon, Sep 30, 2019 at 8:42 AM 'Vladimir Lagunov' via Project Jupyter < > jup...@googlegroups.com <javascript:>> wrote: > >> Hello, >> >> I’m looking for a reliable way of tunneling TCP sockets of pydevd >> <https://www.pydev.org/manual_adv_remote_debugger.html> through >> notebook’s websocket. General tunnel can be easily implemented using Comm, >> but debugger requires a special approach. Debugger is a tool that stops all >> threads of the process to let you debug them, including the main event loop >> thread. And, unfortunately, Comm and shell requests are handled in the same >> thread. >> >> Actually I’ve succeeded in creating a working tunnel for pydevd. A >> special function moves handling of shell requests in a separate thread. All >> shell requests are either being processed in-place if they’re related to my >> protocol extension or being re-queued in a main IOLoop. Pydevd knows about >> that thread and never stops it. All that features are attained by >> monkey-patching different protected methods of kernel.shell_socket, >> kernel.shell_channel, kernel.session, etc. So that black magic is unsteady. >> >> After exploring a code of ipykernel and notebook, I considered that the >> easiest way to make a tunnel for the debugger is to create a separate >> channel. Let’s name that channel «management». It should look like an >> analog of IOPubThread with CommManager and could be used for debugging, >> profiling, collecting metrics at runtime, etc. >> >> What do you think about that idea? Do you see any obvious pitfalls around >> implementing the new channel? Will you accept a patch if me with my >> colleagues will implement it for notebook, ipykernel and probably for a >> gateway? >> >> Thanks, >> Vladimir >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Project Jupyter" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to jup...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jupyter/9a5fd364-6583-40a3-9796-01e92db2cab5%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jupyter/9a5fd364-6583-40a3-9796-01e92db2cab5%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "Project Jupyter" group. To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/ef50e13f-3ee4-4f52-94e3-fca1ed061280%40googlegroups.com.
