Andy, You can trace this quite simply; print the tickless timer value before each zmq_poll in zloop. It should change when you add your new timer.
-Pieter On Thu, Dec 27, 2012 at 5:01 PM, Andy Ballingall TF <[email protected]> wrote: > Hi Pieter, > > On 27 December 2012 13:55, Pieter Hintjens <[email protected]> wrote: >> On Thu, Dec 27, 2012 at 2:53 PM, Andy Ballingall TF >> <[email protected]> wrote: >> >>> Note how my timer registration succeeds, but the polling seems to >>> ignore it? >> >> Then it's because the tickless timer is being miscalculated; it should >> be re-calculated each time you add or remove a timer handler. If not, >> there's a bug. > > I agree with Apostolis below that the zloop code seems correct, with > respect to the calculation of the next timer expiry. Replicating my > scenario with test code would be quite a bit of work, so I took > another look at the zloop implementation again, and I think I can see > what's happening. > > Firstly, my timer mutations were occurring within a message handler, > and the mutation consisted of: > a) Remove existing timer > b) Create a new one. > > The old removed timer and the new timer both have the same 'arg' (in > my case this is an instance of my communications class). > > The reactor loop (in function zloop_start() ) first processes any poll > handlers, then at the end, checks if the zombies list has any timers > to clear. > > By the time the zloop_start() function gets to line 420 (where it > checks for zombies), then the state is: > > Zombies: 1 (arg='this') > > Timers: 2 > 1 = old timer (arg='this', expiry=<old time>) > 2 = new timer (arg = 'this', expiry = <new time>) > > The loop at line 423 will blow away all the timers - including the one > I just added - as it matches the zombie arg. > > That explains why my newly added timer wasn't firing, and why the poll > timeout was set to 1 hour: It's because my newly added timer had been > removed almost immediately! > > If the timer deletion used a reference to the timer object rather than > 'arg' to reference it, then it would ensure that I could call > zloop_timer_end() and subsequently zloop_timer() from within a > handler, without the zloop_start() function removing that newly added > timer... > > In the end, this isn't a problem for me because I've changed my > implementation to use a heartbeat timer which never gets removed and > replaced, but I can see scenarios in the future where it would be good > to reset an existing timer, or delete and add a number of timers > inside a handler... > > Anyway, thanks for your help. > > Andy > > > > > > > > > >> >> -Pieter >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > -- > Andy Ballingall > Senior Software Engineer > > The Foundry > 6th Floor, The Communications Building, > 48, Leicester Square, > London, WC2H 7LT, UK > Tel: +44 (0)20 7968 6828 - Fax: +44 (0)20 7930 8906 > Web: http://www.thefoundry.co.uk/ > > The Foundry Visionmongers Ltd. > Registered in England and Wales No: 4642027 > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
