On 03/02/2012, at 12:05 AM, Chuck Remes wrote: >> > > I think this suggestion is very misguided. I also infer from your suggestion > that you haven't really grok'ed the essence of 0mq. > > There is a simple Rule for using 0mq with threads. That Rule is: > > *Only* use a socket from the thread that created it. > > If you follow that Rule, 0mq and threads get along swimmingly.
Oh, I grok the rule just fine, but perhaps you don't perceive the impact on frameworks where the client doesn't have that kind of control .. or simply doesn't care .. Felix handles several *million* threads. (TCP) socket I/O is done the same way ZMQ does it: in a background thread. ZMQ sockets in Felix currently block the containing pthread, which is no good. To fix that the I/O will be lifted into a background thread. So it is *guaranteed* the I/O will happen in a different thread to the one that created the socket :) But still I doubt any extra locks are required at present since ALL the I/O is done in the background. OTOH if I do what 0MQ does -- and provide more than one background thread, I may need interlocking. It's likely applications such as a webserver will have a set of waiting fibres (one per connection or more), and they'll be farmed out to an arbitrary p-thread allocated from a pool. In that case, how can the "client" possibly obey "the Rule" since they have no control over which p-thread does the work? if you're stuck writing applications in C from the ground up you may well have the design control to obey "the Rule" but you can't assume people using advanced languages or frameworks, including stuff like Python, will have that kind of control. 0MQ isn't the only way to make multi-threaded programming safer. It needs to be able to fit in with other technologies. -- john skaller [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
