From owner-svn-src-all@FreeBSD.ORG Mon Jun 11 22:00:19 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 62218106566B; Mon, 11 Jun 2012 22:00:17 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.c2i.net [212.247.154.34]) by mx1.freebsd.org (Postfix) with ESMTP id 46B2F8FC1A; Mon, 11 Jun 2012 22:00:16 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 285860163; Tue, 12 Jun 2012 00:00:14 +0200 From: Hans Petter Selasky To: Pawel Jakub Dawidek Date: Mon, 11 Jun 2012 23:59:41 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <20120611200507.GG1399@garage.freebsd.pl> <201206112221.51793.hselasky@c2i.net> In-Reply-To: <201206112221.51793.hselasky@c2i.net> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <201206112359.41892.hselasky@c2i.net> Cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" Subject: Re: svn commit: r236909 - head/sbin/hastd X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 22:00:19 -0000 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