fix bad assertion

[zh217]

This assertion will fail under legitimate circumstances.

Consider the following sequence of events:

1. A pull socket is registered
2. Async loop has the socket in the pairings map
3. ZMQ loop has the socket in the socks map
4. The in channel of the socket is closed, and at the same time a message is received from the ZMQ socket
5. Async loop will dissoc the socket from the pairings map
6. ZMQ loop will relay the message to the async loop
7. Async loop will look up the socket from the pairings map, but the socket in question has already been dissoc'ed
8. An exception is thrown, after which nothing works anymore.

[lynaghk]

My concern with your fix is that it will be very difficult for someone to debug the situation where they accidentally forget to provide an out channel.

Did you run into the situation you outlined above, or is it a theoretical concern?

[zh217]

Yes I run into the situation. It happens about every six hours or so in a system where constantly ~100 sockets are open.

A better place to put the assertion would be when creating the socket.

[lynaghk]

Ah, I had no idea anyone was using this library = )

Putting assertions for in/out channels where the socket is created sounds like a good idea; it just needs to match up with the ZeroMQ socket types (since some of them don't always take both).

Would be happy to accept a pull request for that.

[zh217]

Done.

Omitting in channel seems like a bad idea to me, because then you have no way of shutting down the socket. Maybe it is legitimate for systems that don't manage sockets dynamically.

[lynaghk]

Awesome, looks good to me. Did you also want to remove the original assertion you opened the issue about?

[zh217]

Yes it is removed. This pull request contains two commits, the first one does that, and the second one adds the new assertions.

[lynaghk]

Oh, sorry. I didn't notice that. Can you please squash these into a single commit with descriptive message (e.g., "Check for in/out chans when registering socket rather than within internal machinery")