| |||||||||||||
Performance aspectsPerformance aspectsPosted Aug 3, 2006 15:44 UTC (Thu) by kleptog (subscriber, #1183)In reply to: Performance aspects by pphaneuf Parent article: Toward a kernel events interface
The thing is, there already are a whole lot of features to deal with this, many of which are not used as often as they should.
For example, the "minimum amount of data" option exists already for ages for socket (SO_LOWWAT or some such). There's POSIX realtime signals which can be queued and even start a new thread at a particular callback when the signal arrives.
All these things are aimed at the really high end though, 99% of programs don't need to worry about this much...
(Log in to post comments)
Performance aspects Posted Aug 3, 2006 16:20 UTC (Thu) by pphaneuf (guest, #23480) [Link] According to socket(7), there's SO_RCVLOWAT and SO_SNDLOWAT, but they are not changeable on Linux, being always set at 1 (i.e. nothing special). Waiting for POSIX signals is a system call too (in fact, getting them too). I don't think there's anything about starting new threads like that on Linux. Performance-wise, other than holding off readiness events until a certain amount is ready (which appears already has an unimplemented API), I'm fairly happy. Back when I used epoll in edge-triggered mode, I would have liked a way to batch calls to epoll_ctl(), when I re-armed my events, but now I just let the kernel-side level-triggered mode do the work.
Performance aspects Posted Aug 3, 2006 16:37 UTC (Thu) by cventers (subscriber, #31465) [Link] Realtime signals and new-thread callbacks were mentioned in Ulrich's OLSpaper. He went on to show how truly inoptimal they were.
|
|||||||||||||