On 12/01/2009 01:32 AM, Bruce Simpson wrote: > 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().
I don't see how priority matters in poll() anyway. It will return all fds that can have action taken on them..then user-space can process those fds however it wants. One simple optimization might be to check return value of poll/select to see how many items have bits set..then you at least know when you can stop the loop. But, all that said, I think optimizing that is not high priority...we should fix bugs (like that OSPF thing recently reported) at a higher priority. Thanks, Ben _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
