"DBus Embedded" - a clean break

[Ed Hemphill]

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.

We do use epoll(), and its fantastic at being responsive on lots of
connections.
http://sheddingbikes.com/posts/1280829388.html
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.

-Ed

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)
> wrote:
>
> >
> > 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)
> to
> > > > floating-point (libev) back to int milliseconds
> (poll/epoll/select)...
> > >
> > > (Just some nitpicking: neither epoll() nor select() actually take
> msec.)
> >
> > 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
> main
> > 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
> up.
>
> 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
> unlikely.
>
> Lennart
>
> --
> Lennart Poettering - Red Hat, Inc.
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20110121/047039ef/attachment.html>