Messages in this thread | | | Subject | Re: RFC: A revised timerfd API | From | Thomas Gleixner <> | Date | Tue, 18 Sep 2007 11:27:15 +0200 |
| |
On Tue, 2007-09-18 at 11:01 +0200, Michael Kerrisk wrote: > > 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.)
I don't think it is a big problem to have several open file descriptors on a single posix timer without having destructive reads, we just need to store the event count per file descriptor in file->private_data. We solved this in the UIO code already and it works perfectly fine.
tglx
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |