"DBus Embedded" - a clean break

[Lennart Poettering]

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.