[IPython-dev] Sockets by name, adding a control socket...
Tue Nov 16 16:46:34 CST 2010
Boy I am busy these days...continuing on...
On Wed, Nov 3, 2010 at 10:28 PM, Fernando Perez <email@example.com>wrote:
> On Wed, Nov 3, 2010 at 10:11 PM, Brian Granger <firstname.lastname@example.org>
> > 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.
> Our reasoning for putting attribute access there was to keep the -a
> socket strictly for things the user would normally see in his regular
> namespace, and -b for things that had to do with manipulating the
> kernel object itself. While it's true that one can get the kernel via
> 'ip = get_ipython()' and start working on it, that's not the "regular"
> mode of operation in most user activities.
But wouldn't both XREP channels probe the users namespace?
> And Min brought up a compelling point for wanting the separate kernel
> control channel: so that things like abort commands can jump to the
> front of the queue. This will become more important once the web
> notebook makes it natural to queue up multiple cells for execution,
> for example.
Yes, that does make sense. But then I think that the control channel should
*never* touch the user's namespace.
> And once we update the connection logic to use the mechanism Min has
> with a single socket for initial connection and all others
> auto-negotiated after that, having one more socket shouldn't be too
> big of a deal. I do agree with you that we don't want these things
> growing like dandelions, but I don't think we have too many more in
> store, to me this seems like a reasonably complete coverage of what we
I am not too sure of this. If you think about remote connections, this is 1
more firewall port that has to be opened. Also 1 more point of security...
> >> - 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.
> We thought about that but it seemed a little too long... And we looked
> at the actual list of what goes there, right now we have:
> # Streams (stdout, stderr, etc)
> # Python inputs
> # Python outputs
> # Python errors
> # Kernel status
> # Kernel crashes
> It seemed like most of this was the kind of thing that normally shows
> up on i/o streams at a console/log, so while not literally being
> stdout/err, 'iopub' seemed like a reasonable, and short, way to
> describe 'publish all i/o activity produced by the kernel'. I/O is
> more or less by definition a side effect (which is why functional
> languages typically have to do something a bit odd to provide it, as
> it doesn't really fit into a purely functional paradigm)...
I just think that IO is too limiting because of our moving the payload to
this channel. So maybe:
> But if this justification doesn't convince you, I'm happy to
> reconsider (though I'd like to find something a little shorter than
> side_effects, we're likely to use these names a lot everywhere...).
> >> - 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?
> Yes, the k alone didn't seem very nice. kernel_stdin? (In general, I
> think we should avoid run-in words without underscores as much as
> possible). It's a bit long but this one isn't likely to be used
> super-often, and I think it's a good idea to keep explicit the fact
> that this one is a special socket handling something from the kernel,
> rather than client-side stdin.
Yes, I think that kernel_stdin is better.
> Thanks for the feedback!
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IPython-dev