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

raw_input appears to be round-robin for qtconsole #673

ivanov opened this Issue Aug 3, 2011 · 3 comments


None yet
3 participants

ivanov commented Aug 3, 2011

If I start a qtconsole, raw_input() seems to just work. But when I hook up to it from another kernel manager, then raw_input() only responds from qt_console every other time and blocks the other time, and if I attach a 3rd kernel manager, it only responds every 3rd time.

sending stdin_channel.input() from the 2nd and 3rd kernelmanagers always works, regardless of whether or not qtconsole is blocking or properly handling the raw_input.


This comment has been minimized.


minrk commented Aug 3, 2011

Good catch. The stdin socket is definitely the wrong type. We need to do one of the following:

  1. use ROUTER to ask a specific frontend for stdin.
  2. restrict the model to give only one frontend access to stdin (this is what our diagram implies is the case)

what currently happens with multiple frontends is entirely nonsensical: stdin requests are LRU load-balanced across frontends.


This comment has been minimized.


fperez commented Aug 4, 2011

Yup, you caught this :) Thanks for making a proper report for it, we really need to fix this to have real use of multi-client scenarios.


This comment has been minimized.


minrk commented Aug 4, 2011

There are actually several more than the 2 options I proposed, but all would require some amount of handshaking to be added to frontends connecting to the kernel. The one we use now (and #2 above) is probably the worst, since a malicious/accidental connection to the stdin socket would cause this problem in a way the kernel has no way of preventing.

More could be:
3. implement stdin with a pair of PUB/SUB sockets, broadcasting the request to all, and accepting the first reply
4. separate req/rep pairs for each frontend

I think 1. and 3. are the best choices, depending on whether we want to bind the stdin request to the caller who caused it in the first place, or let any frontend respond (more flexible, but potentially weird side effects).

@minrk minrk closed this in a2ac298 Oct 12, 2011

@minrk minrk closed this in 6e92ffd Oct 12, 2011

mattvonrocketstein pushed a commit to mattvonrocketstein/ipython that referenced this issue Nov 3, 2014

use ROUTER/DEALER sockets for stdin
stdin requests are now directed to the frontend that made the execution
request that called raw_input.

allow_stdin flag added to execution_request to indicate whether stdin_requests are allowed.

StdInNotImplementedError exception class added to IPython.core.error, and is raised if raw_input is called from execute requests where allow_input is undefined.

closes ipythongh-673

mattvonrocketstein pushed a commit to mattvonrocketstein/ipython that referenced this issue Nov 3, 2014

Merge branch 'stdin'
Changes stdin channel from REQ-REQ to ROUTER-DEALER, fixing
the round-robin load-balancing of stdin_requests across frontends.
stdin_requests now go to the client that made the execute_request
that prompted the stdin request.

stdin_requests from frontends that do not support stdin will raise an error,
rather than hanging on input that will never arrive.

reviewed by @fperez

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