Blocking behavior of zmq_term is very good for correctly flushing all the messages on termination for network connections. However it seems that this doesn't work so good currently for inproc connections.
For inproc connections with blocking socket.recv() zmq_term might generate TERM on our blocking recv earlier than messages will be flushed to the socket. The issue is with order of operations, currently there is no specific order of when messages will be flushed and when blocking operation exit with TERM. If however zeromq first tried to flush all the messages to all sockets and only after that generated TERM on all blocking socket.recv() operations this way messages weren't loosed for inprocess connections.
Given that inproc sockets have shared buffer, the correct behavior would be to not generate TERM on recv() operations until this shared buffer is empty.
The code that illustrates issue is provided here:
Total message handled, that output by the code is not always 100, as expected, but at times 99 or 98, e.g. some messages are lost.