Skip to content

Blocking cell execution waiting for Widget interaction #311

Description

@kafonek

Hi all,

I am interested in blocking further cell execution in a Jupyter notebook until some sort of widget interaction has occurred. For instance, letting a user perform a "cell -> run all" command, then displaying a dropdown widget in one cell, and blocking in the next cell until the user has selected an option from that dropdown list.

In a regular notebook setup, widget changes (comm_msg over zeromq) won't be picked up by the kernel because it's blocking until the cell is completely executed. If an Asynchronous Loop is involved, then all cells will be executed (from the "cell -> run all") command immediately if they aren't written in an async fashion.

One option is to override the kernel.shell_handlers functions to 'capture' the execute_request messages coming in on the stream while letting the comm_msg events go through, then to 'replay' the execute_request messages after the fact. If I go with that pattern (example, how do I make the output show up in the output cells for the original input cells instead of all in a single cell where the 'replay' happens?

A second option is to have the ipykernel listen for execute_request and comm_* events on different streams. There's been discussion of that idea (@dsblank @AlexTugarev #65, @jasongrout jupyter/jupyter_client#285), but it doesn't look like the issue has moved forward. I don't understand the entire front-end/back-end system to know how significant that change would be. Is this issue a non-starter (#302)?

Thanks.

Activity

  1. Carreau commented on Mar 29, 2018

    @Carreau
    Member

    cc @SylvainCorlay you know quite a bit more about widgets than I, do you have any hindsight ?
    There are some plan to make the ipykernel more aware of async code., that may help but it wont' happen soon.

  2. SylvainCorlay commented on Mar 29, 2018

    @SylvainCorlay
    Member

    In general, people have been trying to do the opposite: prevent the notebook from blocking, for which we offer multiple scenarios.

    I don't think that there is a simple method besides changing the execution model of the kernel, or capturing execution requests as explained above.

  3. kafonek commented on Aug 30, 2018

    @kafonek
    Author

    https://github.com/kafonek/ipython_blocking is out on pypi now as an alpha solution to this issue. I'm sure there's improvements and tweaks that can be made, so I'd appreciate any feedback.

    @SylvainCorlay @maartenbreddels @jasongrout @minrk

  4. davidbrochart commented on Sep 24, 2026

    @davidbrochart
    Collaborator

    Closed in #1565.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions