epoll/libevent vs. AEM (was RE: [cgl_discussion] PoC concall 10/8/03
Fleischer, Julie N
julie.n.fleischer at intel.com
Mon Oct 13 13:09:13 PDT 2003
> I have some update information and thoughts for epoll +
> libevent. Hope it's helpful.
>From previous analysis on the mailing list I have:
For AEM - Meets requirements: scalability for large # event channels - w/forked events; soft RT resp. for ~simultaneous events - with RT patch; events on Xpl types of channels - only timer and socket -->work needed for SCTP; all kernel level
Meets some requirements: is synchronous polling mechanism - http://aem.sourceforge.net/reports/aem-faq-draf0.3.pdf; scalability for large # event chs - epoll + libevent does; soft RT resp. for ~sim events - does, may not be as good as AEM (need analysis); events on Xpl types of chs - supports Xpl channels, only read, but accept/read/write/exception on socket, others impl. dependent, so OK
To sum up, it appears:
- AEM will meet full requirements when complete -- It's on the top-10 because CGL has expressed concern about stability/invasiveness.
- libevent+epoll has a few issues: 1) It's synchronous, not asynchronous. 2) Soft RT response for nearly simultaneous events may not match AEM -- needs testing. 3) libevent can't support SMP (from Forrest's analysis).
Is this enough for us to have a discussion about the Efficient Low-Level Asynchronous Events requirement at the next PoC or F2F? It definitely sounds like AEM should stay on the top-10, though, since it's still unclear if epoll+libevent will fulfill the requirement. (Possibly, though, it fulfills enough of the spirit of the requirement that it's acceptable.)
**These views are not necessarily those of my employer.**
More information about the cgl_discussion