"DBus Embedded" - a clean break
ed at izuma.net
Fri Jan 21 20:43:54 PST 2011
Yes, I felt this same frustration myself when writing our system.
Unfortunately, most non-RT kernels/archs just dont give you sub-u second
We do use epoll(), and its fantastic at being responsive on lots of
An old, but good analysis: http://www.kegel.com/c10k.html#nb.epoll
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.
on your blocking reads, you can send a signal to wake them.
On Fri, Jan 21, 2011 at 12:18 PM, Lennart Poettering <mzqohf at 0pointer.de>wrote:
> On Fri, 21.01.11 16:57, Simon McVittie (simon.mcvittie at collabora.co.uk)
> > On Fri, 21 Jan 2011 at 17:42:47 +0100, Lennart Poettering wrote:
> > > > > On Thu, Jan 20, 2011 at 8:14 AM, Simon McVittie
> > > > > <simon.mcvittie at collabora.co.uk> wrote:
> > > > It also seems rather perverse to go from int milliseconds (libdbus)
> > > > floating-point (libev) back to int milliseconds
> > >
> > > (Just some nitpicking: neither epoll() nor select() actually take
> > My mistake, select takes (seconds and) microseconds. That's a simple
> matter of
> > integer arithmetic, though.
> > The epoll_wait man page claims that epoll_wait and epoll_pwait take
> > milliseconds. (Or is the man page wrong? I haven't got far enough with
> > loop restructuring to actually try epoll yet.)
> > For completeness, poll does take milliseconds, and pselect and ppoll take
> > (seconds and) nanoseconds. The wonderful thing about standards, etc.
> Oops, sorry. I was wrong about epoll. It actually does take msec. Fucked
> timerfd() FTW!
> BTW, instead of using libev I'd recommend everybody to just use epoll()
> together with signalfd() and timerfd(). Might not be portable, and not
> the API isn't the most elegant thing ever invented, but definitely
> capable, performant, accurate and working. And I'd actually be happy
> with dropping compat with other Unixes and other crappy OSes... But it I
> guess that's just me, and there's enough politics in place to make that
> Lennart Poettering - Red Hat, Inc.
> dbus mailing list
> dbus at lists.freedesktop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dbus