lkml.org 
[lkml]   [2007]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Revised timerfd() interface
    On Wed, 5 Sep 2007, Michael Kerrisk wrote:

    > Davide,

    A Michael!


    > > > As I think about this more, I see more problems with
    > > > your argument. timerfd needs the ability to get and
    > > > get-while-setting just as much as the earlier APIs.
    > > > Consider a library that creates a timerfd file descriptor that
    > > > is handed off to an application: that library may want
    > > > to modify the timer settings without having to create a
    > > > new file descriptor (the app mey not be able to be told about
    > > > the new fd). Your argument just doesn't hold, AFAICS.
    > >
    > > Such hypotethical library, in case it really wanted to offer such
    > > functionality, could simply return an handle instead of the raw fd, and
    > > take care of all that stuff in userspace.
    >
    > Did I miss something? Is it not the case that as soon as the
    > library returns a handle, rather than an fd, then the whole
    > advantage of timerfd() (being able to select/poll/epoll on
    > the timer as well as other fds) is lost?

    Why? The handle would simply be a little struct where the timerfd fd is
    stored, and a XXX_getfd() would return it.
    So my point is, I doubt such functionalities are really needed, and I also
    argue that the kernel is the best place for such wrapper code to go.



    - Davide


    -
    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/

    \
     
     \ /
      Last update: 2007-09-05 18:17    [W:3.357 / U:1.112 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site