Re: RFC: A revised timerfd API

["Michael Kerrisk" <mtk-manpages@gmx.net>]

Hello David,

Thanks for taking a look at this.

> On Tue, September 18, 2007 09:30, Michael Kerrisk wrote:
> > ====> b) Create a timerfd interface analogous to POSIX timers
> >
> > Create an interface analogous to POSIX timers:
> > fd = timerfd_create(clockid, flags);
> > timerfd_settime(fd, flags, newtimervalue, &time_to_next_expire);
> > timerfd_gettime(fd, &time_to_next_expire);
> ...
> > ====> c) Integrate timerfd with POSIX timers
> >
> > Make a very simple timerfd call that is integrated with the
> > POSIX timers API.  The POSIX timers API is detailed here:
> > http://linux.die.net/man/3/timer_create
> > http://linux.die.net/man/3/timer_settime
> >
> > Under the POSIX timers API, a new timer is created using:
> >
> > int timer_create(clockid_t clockid, struct sigevent *evp,
> >         timer_t *timerid);
> >
> > We could then have a timerfd() call that returns a file descriptor
> > for the newly created 'timerid':
> >
> > fd = timerfd(timer_t timerid);
> 
> Wouldn't this remove some of the usefulness of the timerfd?
> 
> For example, if a timerfd is one of the fd's that is returned by a
> epoll_wait syscall, you manually need to do the mapping between the
> timerfd and the timerid in order to be able to modify the timer.

You're right, that makes the interface more clumsy. +1 for
the disadvantages.  And of course solution (d) also suffers
this problem.

> The advantage of solution b) above is that the fd is everything that is
> needed to work with the timer.

Yes, true.  Solution (b) would also be relatively easier (for me)
to implement.

> With solution c) you have to keep two
> references to the same timer around and use one of them depending on what
> you want to do with the timer.

Yes.  (And the same for option (d).)

> Also, if the timerfd is close():d, does that remove the underlying timer
> (invalidate the timerid) as well?

My gut feeling would be to say that closing the timerfd would not
remove the underlying timer (so the timerid would remain valid).
One could even do things like recreating a file descriptor
for the timer using another timerfd() call.  

But now that raises the question: what are the semantics if
timerfd() is called  more than once on the same timerid? 
Perhaps a read() from any one of them (destructively)
reads the expiration count, as though one had read from a 
dup()ed the file descriptor.  All in all, solution (c) 
starts to look overly complex, and maybe suffers from 
various dirty corners in the API.  (Solution (d) feels 
slightly better, because the creation of the file descriptor
and the timerid are integrated into a single call, and the
fact that it integrates with an existing API, but
it still has the limitation you describe above.)

Cheers,

Michael