Re: PN_REACTOR_QUIESCED
On Wed, 2015-10-14 at 10:31 -0400, Rafael Schloming wrote: > It wasn't actually an accidental commit. If I recall correctly I > ended up > using it more like a 0xDEADBEEF value. It makes it easy to > distinguish > between the failure mode of an actual hang (e.g. infinite loop or > blocking > call inside a handler) vs reaching a state where there are simply no > more > events to process. I guess you can think of it like a heartbeat in a > way. > It seems like an odd default. Can we make it 0 in the code and set it non-0 in tests if that is needed? Randomly waking up a user app that hasn't asked for heartbeats every sort-of-3-seconds is a surprising behavior. > --Rafael > > On Tue, Oct 13, 2015 at 10:56 AM, Michael Goulish < > mgoul...@redhat.com> > wrote: > > > > > But it's obvious how this constant was chosen. > > > > With circular reasoning. > > > > > > > > > > > > - Original Message - > > > On Mon, 2015-10-12 at 16:05 -0400, aconway wrote: > > > > ... > > > > +1, that looks like the right fix. 3141 is an odd choice of > > > > default, > > > > even for a mathematician. > > > > > > > > > > At this point, I'm desperately trying to find an appropriate pi > > > joke : > > > -) > > > > > > Andrew > > > > > > > >
Re: PN_REACTOR_QUIESCED
It wasn't actually an accidental commit. If I recall correctly I ended up using it more like a 0xDEADBEEF value. It makes it easy to distinguish between the failure mode of an actual hang (e.g. infinite loop or blocking call inside a handler) vs reaching a state where there are simply no more events to process. I guess you can think of it like a heartbeat in a way. --Rafael On Tue, Oct 13, 2015 at 10:56 AM, Michael Goulishwrote: > > But it's obvious how this constant was chosen. > > With circular reasoning. > > > > > > - Original Message - > > On Mon, 2015-10-12 at 16:05 -0400, aconway wrote: > > > ... > > > +1, that looks like the right fix. 3141 is an odd choice of default, > > > even for a mathematician. > > > > > > > At this point, I'm desperately trying to find an appropriate pi joke : > > -) > > > > Andrew > > > > >
Re: PN_REACTOR_QUIESCED
On Mon, 2015-10-12 at 16:05 -0400, aconway wrote: > ... > +1, that looks like the right fix. 3141 is an odd choice of default, > even for a mathematician. > At this point, I'm desperately trying to find an appropriate pi joke : -) Andrew
Re: PN_REACTOR_QUIESCED
But it's obvious how this constant was chosen. With circular reasoning. - Original Message - > On Mon, 2015-10-12 at 16:05 -0400, aconway wrote: > > ... > > +1, that looks like the right fix. 3141 is an odd choice of default, > > even for a mathematician. > > > > At this point, I'm desperately trying to find an appropriate pi joke : > -) > > Andrew > >
Re: PN_REACTOR_QUIESCED
On Sat, 2015-10-10 at 10:57 +0200, Bozo Dragojevic wrote: > Hi Alan, Rafael, > > On 9. 10. 15 21.25, aconway wrote: > > I'm fiddling with the C++ example broker, and when I install a > > debug > > handler, I see that when the broker is doing absolutely nothing > > there > > is a PN_REACTOR_QUIESCED event about every 3 seconds. Does anybody > > know > > what this is about? Why is the reactor waking up just to tell us > > that > > it is asleep? > > > > > > On first sight seems like a debug thing accidentally committed. > > I think something like this is in order: > > $ git diff > diff --git a/proton-c/src/reactor/reactor.c b/proton > -c/src/reactor/reactor.c > index 6b328bc..7542d4c 100644 > --- a/proton-c/src/reactor/reactor.c > +++ b/proton-c/src/reactor/reactor.c > @@ -484,7 +484,6 @@ void pn_reactor_stop(pn_reactor_t *reactor) { > > void pn_reactor_run(pn_reactor_t *reactor) { >assert(reactor); > - pn_reactor_set_timeout(reactor, 3141); >pn_reactor_start(reactor); >while (pn_reactor_process(reactor)) {} >pn_reactor_stop(reactor); > > workaround is to pn_set_reactor_timeout(r, 0) in PN_REACTOR_INIT in > your > broker. +1, that looks like the right fix. 3141 is an odd choice of default, even for a mathematician.
Re: PN_REACTOR_QUIESCED
Hi Alan, Rafael, On 9. 10. 15 21.25, aconway wrote: > I'm fiddling with the C++ example broker, and when I install a debug > handler, I see that when the broker is doing absolutely nothing there > is a PN_REACTOR_QUIESCED event about every 3 seconds. Does anybody know > what this is about? Why is the reactor waking up just to tell us that > it is asleep? > > On first sight seems like a debug thing accidentally committed. I think something like this is in order: $ git diff diff --git a/proton-c/src/reactor/reactor.c b/proton-c/src/reactor/reactor.c index 6b328bc..7542d4c 100644 --- a/proton-c/src/reactor/reactor.c +++ b/proton-c/src/reactor/reactor.c @@ -484,7 +484,6 @@ void pn_reactor_stop(pn_reactor_t *reactor) { void pn_reactor_run(pn_reactor_t *reactor) { assert(reactor); - pn_reactor_set_timeout(reactor, 3141); pn_reactor_start(reactor); while (pn_reactor_process(reactor)) {} pn_reactor_stop(reactor); workaround is to pn_set_reactor_timeout(r, 0) in PN_REACTOR_INIT in your broker. Bozzo