locks in stdout

[minrk]

The addition of the IOPub thread in 4.3 for async threaded output uses locks in a few places to ensure threadsafety. This generally works, but causes a problem in one particular case: interactive debugging. The reason being that stepping through an interactive debug session introduces concurrency between a non-running thread (the debugging thread) and the debugger itself, allowing for the following sequence of events:

1. debugged thread* acquires lock on stdout buffer, pauses waiting for next step
2. debugger UI tries to draw the current frame to stdout, and waits for debugged thread to release the lock, which never happens.

Which ultimately means that you can't debug anything with a print statement (post-mortem debugging is not affected).

I believe that I can write a lock-free implementation, but I might need to use inproc zmq sockets to do so. I will see if I can do it with plain os.pipe as well, but I'm not sure that I can as easily.

cc @garth-wells who reported the issue.

[minrk]

Arg, I got this all working without locks, only using IOLoop.add_callback, but then ran into the fact that add_callback itself uses a lock for threadsafety. In order for this to work, I have to ensure that neither stream.write nor stream.flush touch a lock at any point. I think I can do this relatively easily for write, but flush is harder because it should block until the socket.send has happened, which is necessarily inter-thread coordination.

[minrk]

#199 appears to work without any locks.