[Xorp-hackers] Selector overhead; SelectorList bugs

[Bruce Simpson]

Bruce Simpson wrote:
> Just thinking aloud here about the implications of the performance 
> profiling experiments I've been doing.
>
> There's room for improvement here. If someone stepped up to rewriting 
> the Selector to use poll(), that would give us more flexibility with I/O 
> ordering, but remain portable to the UNIX platforms we support.
>   

I had a brief exchange in private message with an old friend of mine. 
She mentioned that she'd been hacking with OpenSolaris' port(3C). Looks 
to me like Sun went ahead and 'did' I/O completion ports, NT style.

So it seems we've got 4 nifty alternatives, none of them particularly 
portable: port, Apple's Grand Central Dispatch, kqueue, and epoll.

With epoll, lowest fds get highest dispatch priority. With GCD, you need 
to explicitly push objects into priority queues; looks like it's coming 
to Linux soon. It's not immediately clear to me how to do relative I/O 
priority with port(3C). kqueue is BSD only.

Sounds like a job for good old poll().