[Xorp-hackers] fix assert in selector.cc

[Ben Greear]

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 <greearb at candelatech.com> 
Candela Technologies Inc  http://www.candelatech.com