Potentially fixes #39 crash on exit when using with IPython / Jupyter

[indivisibleatom]

From what I understand debugging around, Jupyter uses ZMQ as well, and, the exit functionality of transplant terminates the context, assuming it has complete ownership of it. An easy fix is to actually create an owned ZMQ context, which is what this change is. This fixes #39 that was reproing on Ubuntu 16.04 for me. Another possible fix is to not close the context, in which case, it should be automatically closed on garbage collection, but I have not tested such a change.

[bastibe]

Very cool! Thank you very much! Do you know how this interacts with IPython? Does this influence IPython's ZMQ connection?

[indivisibleatom]

Thanks for the kind words :). It gets rid of the influence. Earlier, transplant and IPython were using the same ZMQ connection (the same global context). Terminating this connection under transplant was "pulling the rug" under IPython -- and, it could no longer communicate with the HTML front-end, and its kernel's that run in the back-end. Now, transplant uses, and terminates its own ZMQ, not touching the global one that is being used by IPython as well.

[bastibe]

Thank you very much! As far as I understand the documentation, this seems to be the right thing to do.

The thing I don't understand is how Python Context.instance and Context.__init__ map to zmq_ctx_new in C. Do you know how these two methods are related to the C function?

[indivisibleatom]

From https://github.com/zeromq/pyzmq/blob/550ddc04c3ce67cdb58b6fb6499274dc7f82891c/zmq/sugar/context.py and https://github.com/zeromq/pyzmq/blob/550ddc04c3ce67cdb58b6fb6499274dc7f82891c/zmq/backend/cython/context.pyx, it would appear that Context.init calls zmq_ctx_new finally, and, Context.instance returns a cached one if one has been created.

[bastibe]

Well thank you very much! This has been enlightening!