[SSSD] [PATCH] Make periodic checks for DNS timeouts

Dmitri Pal dpal at redhat.com
Thu Jan 14 13:39:07 UTC 2010


Stephen Gallagher wrote:
> On 01/14/2010 08:32 AM, Dmitri Pal wrote:
> > Stephen Gallagher wrote:
> >> On 01/13/2010 05:38 PM, Simo Sorce wrote:
> >>> On Wed, 13 Jan 2010 16:54:54 -0500
> >>> Stephen Gallagher <sgallagh at redhat.com> wrote:
> >>>> It's bad practice to modify current_time in a tevent_timer handler.
> >>> I agree with the nack, but I want to explain why it is really bad! :)
> >>> There is no problem in using the tevent_timer current_time in the
> >>> handler, it is just a copy that will die as soon as you return
> from the
> >>> handler.
> >>> The real problem here is that current_time is not the *actual*
> time, it
> >>> can easily be (0, 0).
> >>> This means that setting it to tv_sec += 1 means causing a busy loop
> >>> that spins as fast as it can because tv_sec = 1 is always in the past
> >>> and causes tevent to fire immediately.
> >>> Simo.
> >>
> >> Well, I would consider that a bug in the tevent API, then. What's the
> >> value at all of passing a "current_time" argument to the caller if
> it is
> >> not accurate. There are cases where a user may want to use this
> value to
> >> examine how long after the timer was set to fire it ACTUALLY fired.
> >>
> >> If there are ever cases where current_time == { 0, 0 }, this should be
> >> logged as a bug in tevent.
> >>
> >> But this argument is tangential to this patch review.
> >>
> >>
> > I disagree.
> > The value of passing { 0, 0 } in current_time is to loop once
> immediately.
> > As far as I understand this is a preferred way to do it.
> > Simo?
>
>
> I think you misunderstand the context, Dmitri. This is in the callback
> itself, after the timer has fired. It passes a value into the callback
> called current_time. Simo has implied that this value is not always the
> ACTUAL current time, which I consider to be a bug.
>
> You are correct that passing { 0, 0 } to the tevent_add_timer() function
> is the preferred way to say "do it now".
>
>

Ah, Ok sorry for confusion.

_______________________________________________
sssd-devel mailing list
sssd-devel at lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel

-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/




More information about the sssd-devel mailing list