[IPython-dev] Zmq branch on LP: re-created.

[Brian Granger]

On Fri, Apr 30, 2010 at 2:12 AM, Hans Meine <hans_meine at gmx.net> wrote:
> Am Freitag 30 April 2010 01:30:05 schrieben Sie:
>> Hans, were you using pure python sockets?
>
> I was about to say no, but actually we did:
>  s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> although we later used Qt's QSocketNotifier around it (by taking s.fileno()),
> so the select() would happen from within C++.
>
>> We're trying to avoid any
>> python code in the sockets layer, so that message queuing can continue
>> to happen even if the kernel is running blocking code (e.g. numpy).
>> zmq does that by releasing the gil for most of its operations.  Was
>> that not an issue for you guys?
>
> I am not sure I understand the problem.  Of course, the backend could (and
> would) block and not respond to the commands, so for example completion would
> not work during program execution.  But I don't see a way around that.
> Messages would not be queued as in 0mq, but I guess the OS would maintain some
> buffer.

With 0MQ, the heartbeat responder will be able to reply *while* the
kernel executes code of any kind as the heartbeat responder will run
in a native C++ that doesn't hold the GIL.

> Sorry if I could not really answer your question; I guess my memory is already
> too faint (this was 2003 according to the /CVS/ logs..).
>
> Anyhow, the 0mq approach is certainly better for the main communication, I was
> just wondering about the detection of a crashed backend.
>
> Best,
>  Hans
> _______________________________________________
> 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