Yes, I felt this same frustration myself when writing our system. Unfortunately, most non-RT kernels/archs just dont give you sub-u second response.<br><br>We do use epoll(), and its fantastic at being responsive on lots of connections. <br> <a href="http://sheddingbikes.com/posts/1280829388.html">http://sheddingbikes.com/posts/1280829388.html</a><br>An old, but good analysis: <a href="http://www.kegel.com/c10k.html#nb.epoll">http://www.kegel.com/c10k.html#nb.epoll</a><br> <br>My final solution with all this was to maintain threads, w/ blocking reads, on connections I simply had to have super low latency response. And then use epoll for the rest, so as not to have too many threads. But if you are looking for a one-size fits all AIO solution... i doubt you will find it. I use a dummy pipe FD in my epoll sets to wake up the threads.<br> <br>on your blocking reads, you can send a signal to wake them.<br><br>-Ed<br><br><div class="gmail_quote">On Fri, Jan 21, 2011 at 12:18 PM, Lennart Poettering <span dir="ltr"><<a href="mailto:mzqohf@0pointer.de">mzqohf@0pointer.de</a>></span> wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Fri, 21.01.11 16:57, Simon McVittie (<a href="mailto:simon.mcvittie@collabora.co.uk">simon.mcvittie@collabora.co.uk</a>) wrote:<br> <br> ><br> > On Fri, 21 Jan 2011 at 17:42:47 +0100, Lennart Poettering wrote:<br> > > > > On Thu, Jan 20, 2011 at 8:14 AM, Simon McVittie<br> > > > > <<a href="mailto:simon.mcvittie@collabora.co.uk">simon.mcvittie@collabora.co.uk</a>> wrote:<br> > > > It also seems rather perverse to go from int milliseconds (libdbus) to<br> > > > floating-point (libev) back to int milliseconds (poll/epoll/select)...<br> > ><br> > > (Just some nitpicking: neither epoll() nor select() actually take msec.)<br> ><br> > My mistake, select takes (seconds and) microseconds. That's a simple matter of<br> > integer arithmetic, though.<br> ><br> > The epoll_wait man page claims that epoll_wait and epoll_pwait take<br> > milliseconds. (Or is the man page wrong? I haven't got far enough with main<br> > loop restructuring to actually try epoll yet.)<br> ><br> > For completeness, poll does take milliseconds, and pselect and ppoll take<br> > (seconds and) nanoseconds. The wonderful thing about standards, etc.<br> <br> </div>Oops, sorry. I was wrong about epoll. It actually does take msec. Fucked<br> up.<br> <br> timerfd() FTW!<br> <br> BTW, instead of using libev I'd recommend everybody to just use epoll()<br> together with signalfd() and timerfd(). Might not be portable, and not<br> the API isn't the most elegant thing ever invented, but definitely<br> capable, performant, accurate and working. And I'd actually be happy<br> with dropping compat with other Unixes and other crappy OSes... But it I<br> guess that's just me, and there's enough politics in place to make that<br> unlikely.<br> <div class="im"><br> Lennart<br> <br> --<br> Lennart Poettering - Red Hat, Inc.<br> _______________________________________________<br> </div><div><div></div><div class="h5">dbus mailing list<br> <a href="mailto:dbus@lists.freedesktop.org">dbus@lists.freedesktop.org</a><br> <a href="http://lists.freedesktop.org/mailman/listinfo/dbus" target="_blank">http://lists.freedesktop.org/mailman/listinfo/dbus</a><br> </div></div></blockquote></div><br>