[IPython-dev] Sockets by name, adding a control socket...
Brian Granger
ellisonbg at gmail.com
Thu Nov 4 01:11:40 EDT 2010
On Wed, Nov 3, 2010 at 9:58 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi folks,
>
> [ sorry for not having replied to a few mails on the list and starting
> a new thread, I'm trying to avoid bottlenecking Min right now. I'll
> catch up with the list asap]
>
> Min and I today had a long discussion about the messaging spec and our
> sockets, with an eye towards harmonizing as much as possible the
> design of the kernels in the parallel code with that of the
> interactive one (as those guys will get merged hopefully soon).
>
> As usual, this is all based on our reference doc:
> http://ipython.scipy.org/doc/nightly/html/development/messaging.html
>
> There are two main points:
>
> 1. Our 'XREP' socket does too much, and it would be cleaner if we
> break it into two. Right now that socket manages both control
> commands (liek connect or shutdown) and things related to user
> 'shell-like' activity (code execution, object info, history, etc). In
> the parallel code Min uses a separate control socket, and it seems
> clear we should do the same here. So the plan would be to have two
> sockets (we'll get to the names later):
>
> XREP-a: used for
> - code execution
> - object info
> - completion
> - history
> - anything else that could come up in the future that's along these
> lines (i.e. mostly user namespace-related manipulations)
>
> XREP-b: used for:
> - connect
> - shutdown
> - abort
> - kernel attribute access
> - other kernel-specific manipulations
The connect/shutdown/abort logic does seem to to together, but kernel
attribute access seems to go with the XREP-a things. For the parallel
stuff, the different between these two types of XREP channels makes
sense, because they are talking to different processes. But here, it
is just 1 process, so I am not sure it makes sense. I am a little
concerned about un-needed proliferation of channels.
>
> 2. We should name all of our sockets based on what they do, not on the
> zmq socket type they use. Min and I scribbled a bunch on paper and
> came up with:
>
> - XREP-a: 'shell'. It handles all the things that are 'shell-like'.
> - XREP-b: 'control'. It handles all kernel control stuff.
> - PUB: 'iopub'. This publishes the i/o streams.
> - REQ: 'kstdin'. This is the socket that forwards the kernel's stdin
> when needed.
> - 'heartbeat': can stay, it's already named by function and not by type
Yep, we definitely need better names. Some comments:
> - XREP-a: 'shell'. It handles all the things that are 'shell-like'.
> - XREP-b: 'control'. It handles all kernel control stuff.
Both of these are pretty good if we separate the XREP channel into 2.
> - PUB: 'iopub'. This publishes the i/o streams.
But we publish more than the io streams on this channel. In reality,
it is for sideeffects, so would that name make sense.
> - REQ: 'kstdin'. This is the socket that forwards the kernel's stdin
I think he "k" is a bit too short and confusing. Maybe kernelstdin?
Or just stdin?
> Variations, suggestions, etc, all welcome.
>
> We think Min will start updating the parallel code to follow this
> convention, minor tweaks can always be made later but I doubt we'll
> want to make major changes. But feedback on the names is welcome, if
> anyone has any.
Great, glad you were able to talk about this.
Cheers,
Brian
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com
More information about the IPython-dev
mailing list