svn commit: r236909 - head/sbin/hastd

[Hans Petter Selasky]

On Monday 11 June 2012 22:21:51 Hans Petter Selasky wrote:
> On Monday 11 June 2012 22:05:07 Pawel Jakub Dawidek wrote:
> > On Mon, Jun 11, 2012 at 07:21:00PM +0000, Hans Petter Selasky wrote:
> > > Author: hselasky
> > > Date: Mon Jun 11 19:20:59 2012
> > > New Revision: 236909
> > > URL: http://svn.freebsd.org/changeset/base/236909
> > > 
> > > Log:
> > >   Use the correct clock source when computing timeouts.
> > 
> > Could you please explain why? As you can see some lines above in
> 
> > cv_init(), we initialize condition variable with CLOCK_MONOTONIC too:
> Sorry, this was a mistake clearly. I will revert ASAP. Pointyhat to me.
> 
> My test program didn't take the setattr into account.
> 
> However, while at it, what is the default clock used by
> pthread_cond_timedwait(). In libusb we don't set any clock, and can we
> depend on that CLOCK_REALTIME is the default clock used? Else I should
> probably make a patch there.
> 
> man pthread_cond_timedwait() is silent!
>

Hi,

Some more questions:

While doing my test, I traced pthread_cond_timedwait() into 
"./kern/kern_umtx.c" where the time is subtracted again, so the actual time 
value is not that important, but there are some other problems:

If the time structure argument passed to pthread_cond_timedwait() in 9-stable 
is negative, for example the seconds field, the above mentioned function will 
just return! See ./libkse/thread/thr_cond.c

int
_pthread_cond_timedwait(pthread_cond_t * cond, pthread_mutex_t * mutex,
                       const struct timespec * abstime)
{
        struct pthread  *curthread = _get_curthread();
        int     rval = 0;
        int     done = 0;
        int     mutex_locked = 1;
        int     seqno;

        THR_ASSERT(curthread->locklevel == 0,
            "cv_timedwait: locklevel is not zero!");

        if (abstime == NULL || abstime->tv_sec < 0 || abstime->tv_nsec < 0 ||
            abstime->tv_nsec >= 1000000000)
                return (EINVAL);

CLOCK_MONOTONIC: 18077 (seconds)
CLOCK_REALTIME: 1339451481 (seconds)

CLOCK_REALTIME will at some point become negative. Will libusb's timeout 
functionality stop working then, because pthread_cond_timedwait() has a check 
for negative time?

Or is hastd wrong, that it can compute a timeout offset which is outside the 
valid range, because it uses a simple:

tv_sec += timeout?
tv_sec %= 1000000000; /* Is this perhaps missing in hastd and other drivers 
???? */

What is the modulus which should be used for tv_sec?

--HPS