[IPython-dev] threadsafe widgets

MinRK benjaminrk at gmail.com
Fri Jan 9 19:25:15 EST 2015

Since there’s already a single-threaded eventloop running (tornado), the
easiest way to ensure that actions in threads are properly serialized is to
hand them off via IOLoop.add_callback. This has the advantage over the
mutexes-everywhere approach that there isn’t anything to do in the vanilla
single-threaded case.

Where to put this serialization is a bit of an open question. The simplest
place to do it is on Session itself, since it would be always correct, but
Session isn’t always used in the context of an IOLoop, so to do it at that
level would require the most general, and thus most costly, approach (mutex
on every send/recv). We could add a send method on Kernel that does any
threading checks outside of Session, assuming that tornado is involved,
which is always True when there’s a Kernel, unlike for Session.

A mockup of threadsafe send in a tornado context:

def threadsafe_send(*args, **kwargs):
    if not in_main_thread:
        # can't touch zmq sockets except from main thread
        # call me again ASAP from the main thread
        io_loop.add_callback(threadsafe_send, *args, **kwargs)


The advantage of this over a mutex is that there’s no lock to grab in the
99% case where it is actually called from the main thread.

The issue of mixed-up messages is actually a slightly separate from libzmq
sockets themselves not being threadsafe. This is additional thread-unsafety
provided by pyzmq’s send/recv_multipart, which was allowed because the
underlying C socket is also not threadsafe. Making pyzmq itself threadsafe
was considered (implemented, even), but it’s easy enough to do this at the
application level that pyzmq doesn’t provided it for performance reasons.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20150109/ea36ec3a/attachment.html>

More information about the IPython-dev mailing list