login
Header Space

 
 

Re: RFC: A revised timerfd API

Score:
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: "David Härdeman" <david@...>
Cc: <lee.schermerhorn@...>, <torvalds@...>, <vda.linux@...>, <rdunlap@...>, <corbet@...>, <hch@...>, <tglx@...>, <akpm@...>, <linux-kernel@...>, <geoff@...>, <drepper@...>, <davidel@...>
Date: Tuesday, September 18, 2007 - 5:01 am

Hello David,

Thanks for taking a look at this.


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


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


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


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
-
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
RFC: A revised timerfd API, Michael Kerrisk, (Tue Sep 18, 3:27 am)
Re: RFC: A revised timerfd API, Davide Libenzi, (Tue Sep 18, 12:51 pm)
Re: RFC: A revised timerfd API, Michael Kerrisk, (Sat Sep 22, 9:12 am)
Re: RFC: A revised timerfd API, Davide Libenzi, (Sat Sep 22, 5:07 pm)
Re: RFC: A revised timerfd API, Michael Kerrisk, (Sun Sep 23, 1:33 pm)
Re: RFC: A revised timerfd API, Davide Libenzi, (Sun Sep 23, 2:33 pm)
Re: RFC: A revised timerfd API, Davide Libenzi, (Sun Sep 23, 2:41 pm)
Re: RFC: A revised timerfd API, Michael Kerrisk, (Sun Sep 23, 3:03 pm)
Re: RFC: A revised timerfd API, Thomas Gleixner, (Sat Sep 22, 5:26 pm)
Re: RFC: A revised timerfd API, Davide Libenzi, (Sat Sep 22, 7:21 pm)
Re: RFC: A revised timerfd API, Thomas Gleixner, (Sat Sep 22, 1:10 pm)
Re: RFC: A revised timerfd API, Bernd Eckenfels, (Sat Sep 22, 10:32 am)
Re: RFC: A revised timerfd API, Michael Kerrisk, (Sat Sep 22, 12:07 pm)
Re: RFC: A revised timerfd API, David , (Sat Sep 22, 7:37 pm)
Re: RFC: A revised timerfd API, Thomas Gleixner, (Sat Sep 22, 1:05 pm)
Re: RFC: A revised timerfd API, Michael Kerrisk, (Tue Sep 18, 3:30 am)
Re: RFC: A revised timerfd API, Thomas Gleixner, (Tue Sep 18, 5:10 am)
Re: RFC: A revised timerfd API, Michael Kerrisk, (Tue Sep 18, 5:30 am)
Re: RFC: A revised timerfd API, Thomas Gleixner, (Tue Sep 18, 5:42 am)
Re: RFC: A revised timerfd API, Michael Kerrisk, (Tue Sep 18, 7:08 am)
Re: RFC: A revised timerfd API, Thomas Gleixner, (Tue Sep 18, 7:30 am)
Re: RFC: A revised timerfd API, David , (Tue Sep 18, 9:13 am)
Re: RFC: A revised timerfd API, Michael Kerrisk, (Sat Sep 22, 9:03 am)
Re: RFC: A revised timerfd API, David , (Tue Sep 18, 4:05 am)
Re: RFC: A revised timerfd API, Michael Kerrisk, (Tue Sep 18, 5:01 am)
Re: RFC: A revised timerfd API, Thomas Gleixner, (Tue Sep 18, 5:27 am)
speck-geostationary