[Xorp-hackers] Selector overhead; SelectorList bugs

[Bruce Simpson]

Bruce Simpson wrote:
> I couldn't find any priority scheme in epoll. It looks as though its 
> internal RB-tree is keyed by fd, game over; no relative I/O priority.
>   
So epoll and select() have the same issue -- lowest fd wins. We could 
work around that with using dup2(), but that means Selector needs to 
manage the process-wide fd space. We have a number of entities in the 
code which don't expect their underlying FD to change, and it is a bit 
of a gross layering violation.

Selector could do the remapping behind their backs to implement I/O 
classes in this way, by keeping the dup2() copy private, but the fact 
that it has to manage the fd space, is what shoots this idea down -- 
it's a hack.

There are a number of situations where we could get pending I/O 
notifications delivered to userland at the same time. DTrace would be 
great for mapping them out.

Using poll() is likely to give us the result we want (make sure this 
crucial thing happens first), with less hacking.

Having said all this, I'm not the only one who has believed the userland 
scheduler in XORP needs more work...