Bruce Simpson wrote: > Ben, > > Thanks for your patch. Can you clarify how/when this condition is > triggered, with a full backtrace please? > > It would be very helpful to get a root cause analysis on this > condition you are observing, before a 1.7-RC. > > Ben Greear wrote: >> It's possible this is caused by some of my own patches, but I think >> it's a logic >> bug: If the only fd ISSET has infinite priority, it will not be >> chosen and >> will hit the assert at the bottom of the method. > > XorpTask::PRIORITY_INFINITY seems to mean 'this task has infinitely > low priority', and therefore should not be run. Using KScope, I do not > see any place in the code where a XorpTask is being explicitly > instantiated with PRIORITY_INFINITY. Perhaps the bug lies elsewhere, > and the assertion is triggered for some other reason? Maybe so. The backtrace from this was near useless because it doesn't show what poked the events into the main loop. > > It is likely that the EventLoop/SelectorList code would be completely > replaced by the boost::asio::io_service reactor class when Boost is > introduced. I'll see if I can reproduce the bug with the svn tree on Linux.
Thanks, Ben -- Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
