lkml.org 
[lkml]   [2011]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFCv4] timerfd: add TFD_NOTIFY_CLOCK_SET to watch for clock changes
    On Thu, Mar 10, 2011 at 09:48:03AM +0100, Arnd Bergmann wrote:
    > On Wednesday 09 March 2011 15:36:51 Alexander Shishkin wrote:
    > > This is another attempt to approach notifying userspace about system
    > > clock changes. The other one is using an eventfd and a syscall [1]. In
    > > the course of discussing the necessity of a syscall for this kind of
    > > notifications, it was suggested that this functionality can be achieved
    > > via timers [2] (and timerfd in particular [3]). This idea got quite
    > > some support [4], [5], [6] and some vague criticism [7], so I decided
    > > to try and go a bit further with it.
    >
    > I don't understand from your description or from the patch how user
    > space gets notified. From your description, I would have expected
    > to see a change to the timerfd_poll() function to check if the
    > clock has changed, possibly returning POLLPRI, but the only such
    > change I can see is in the timerfd_read() function. Don't you need
    > to change poll() so that a task knows when to call read()?

    Luckily, no changes for the _poll function were required, because the
    notification code reuses the ctx->ticks counter of timerfds. IOW, poll
    wakes up in the same way as before.

    > > +/* TFD_NOTIFY_CLOCK_SET timers go here */
    > > +static DEFINE_SPINLOCK(notifiers_lock);
    > > +static LIST_HEAD(notifiers_list);
    >
    > Maybe I was the only one to be confused by this, but I think t
    > he naming is slightly misleading, because it's easy to confuse
    > with a struct notifier_block. You could of course use the
    > notifier API instead of building your own, but if you don't,
    > I'd recommend coming up with a different name.

    Point taken.

    > I also think that a mutex would be better here than a spinlock.
    > It's unlikely to be under heavy contention, but if you have
    > a lot of threads, it could be held for a significant amount
    > of time.

    Indeed, thanks!

    Regards,
    --
    Alex


    \
     
     \ /
      Last update: 2011-03-10 15:21    [W:2.709 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site