Pieter, It has to flush the messages from that socket to guarantee that all messages sent before ETERM are actually pushed to the network.
However, the socket has to be protected somehow, because if socket thread sends a message and term thread flushes the messages at the same time they are stepping on each other toes. Martin On 12/03/2010 08:24 AM, Pieter Hintjens wrote: > Why would it even wait? The socket can catch the eterm flag at any > point, it is asynchronous between the two threads. > > - Pieter > > On 2 Dec 2010 20:50, "Martin Sustrik" <sust...@250bpm.com > <mailto:sust...@250bpm.com>> wrote: > > Hi Pieter, > > > >> If sockets are not in a critical section, can zmq_term not perform > >> single-bit changes safely anyhow? > > > > Right. That would basically mean implementing a spin-lock in the user > > space. zmq_term thread spins while the socket thread is in a 0MQ call. > > When socket thread exits the function, the zmq_term thread sets a > > "terminated" flag and proceeds with flushing the messages from the > socket. > > > > The question is whether such a spin-lock would be any faster when > > compared to standard mutex. > > > > Martin > > _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
