On Feb 16, 2011, at 9:08 AM, Pieter Hintjens wrote: > On Wed, Feb 16, 2011 at 3:47 PM, Chuck Remes <cremes.devl...@mac.com> wrote: > >> 1. The publisher pushed too much data to its socket... >> I fixed it by finally detecting and repairing the "weekend clock skip" bug. >> So it's not really "fixed" in the 0mq library; I just avoid the condition > > Indeed... the problem is still there and will come back to hit > someone. Nothing you've said suggests it's an OS X issue. If your > hypothesis #1 is correct it should be easy to reproduce with a minimal > publisher and subscribers, not even needing a reactor. > > Could you explain in pure 0MQ terms a scenario you think would provoke > this, and I'll whip up a test case and see if I can make it die on > Linux.
Pieter, take a look at the subject heading. This *was* on linux. :) I ran into the condition very quickly on OSX even before hitting that "weekend time skip" bug which is why I moved to linux for testing. On linux it chugged through a lot more data before it failed the same way. So, it isn't really specific to one OS. Linux fails the same way as OSX. Here's a step-by-step explanation in pure 0mq terms to replicate. 1. On a single thread, have two 0mq sockets. SocketA is a PUB socket and SocketB is a SUB socket. SocketB should subscribe to everything. 2. Have SocketA do a non-blocking send for a few million messages in a tight loop. Do *not* allow SocketB any chance to recv until SocketA's loop is complete. 3. When SocketA's publishing is complete, let SocketB do a non-blocking recv until EAGAIN. 4. See if #2 or #3 fails. cr _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
