You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jeff Trawick <tr...@attglobal.net> on 2002/07/02 15:39:31 UTC
watch out for thread_cond_timedwait problems
I dunno what the cause is yet, but I'm getting testlock failures for
the last day or so.
Tru64:
Run of ./testlock -f /tmp/rasub failed, exit status is 63488.
stdout:
APR Locks Test
==============
thread_mutex test
Initializing the mutex OK
Starting all the threads OK
Waiting for threads to exit OK
Test passed
thread_rwlock Tests
Initializing the apr_thread_rwlock_t OK
Starting all the threads OK
Waiting for threads to exit OK
Test passed
thread_cond Tests
Initializing the first apr_thread_mutex_t OK
Initializing the second apr_thread_mutex_t OK
Initializing the apr_thread_cond_t OK
Starting all the threads OK
Waiting for threads to exit OK
Test passed
thread_cond_timedwait Tests
Initializing the first apr_thread_mutex_t OK
Initializing the apr_thread_cond_t OK
Waiting for condition for 5 seconds Failed! (bad timer)
stderr:
thread_cond_timedwait test failed : [22] Invalid argument
AIX:
Run of ./testlock failed, exit status is 63488.
stdout:
APR Locks Test
==============
thread_mutex test
Initializing the mutex OK
Starting all the threads OK
Waiting for threads to exit OK
Test passed
thread_rwlock Tests
Initializing the apr_thread_rwlock_t OK
Starting all the threads OK
Waiting for threads to exit OK
Test passed
thread_cond Tests
Initializing the first apr_thread_mutex_t OK
Initializing the second apr_thread_mutex_t OK
Initializing the apr_thread_cond_t OK
Starting all the threads OK
Waiting for threads to exit OK
Test passed
thread_cond_timedwait Tests
Initializing the first apr_thread_mutex_t OK
Initializing the apr_thread_cond_t OK
Waiting for condition for 5 seconds Failed! (bad
timer)
stderr:
thread_cond_timedwait test failed : [22] A system call received a
parameter that is not valid.
Linux:
Run of ./testlock failed, exit status is 63488.
stdout:
APR Locks Test
==============
thread_mutex test
Initializing the mutex OK
Starting all the threads OK
Waiting for threads to exit OK
Test passed
thread_rwlock Tests
Initializing the apr_thread_rwlock_t OK
Starting all the threads OK
Waiting for threads to exit OK
Test passed
thread_cond Tests
Initializing the first apr_thread_mutex_t OK
Initializing the second apr_thread_mutex_t OK
Initializing the apr_thread_cond_t OK
Starting all the threads OK
Waiting for threads to exit OK
Test passed
thread_cond_timedwait Tests
Initializing the first apr_thread_mutex_t OK
Initializing the apr_thread_cond_t OK
Waiting for condition for 5 seconds Failed (late TIMEUP)!
The timer returned in 5292029 usec!
stderr:
thread_cond_timedwait test failed : [20507] The timeout specified has expired
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: interval times Re: watch out for thread_cond_timedwait problems
Posted by Cliff Woolley <jw...@virginia.edu>.
On Tue, 2 Jul 2002, Aaron Bannert wrote:
> I'm not really comfortable doing a change like this without changing
> the name for apr_time_t. If we are going to change the semantics
> we need to create a new identifier.
AFAIK, changing the name has been part of the plan all along. I was under
the impression that Brian was just doing the preliminary legwork.
That said, apr_time_t (whatever it ends up being called) being binary
usecs means that apr_interval_time_t (whatever it ends up being called)
*must* also be binary usecs.
apr_interval_time_t is defined as "the difference between two apr_time_t's".
If somebody wants to pass a value to a syscall, that's not the purpose of
apr_interval_time_t. Besides, I'd think those values would often be in
seconds and not microseconds anyway, no?
--Cliff
Re: interval times Re: watch out for thread_cond_timedwait problems
Posted by Aaron Bannert <aa...@clove.org>.
On Tue, Jul 02, 2002 at 11:13:58AM -0700, Brian Pane wrote:
> If we change apr_time_t to use binary microseconds, we'll have to
> decide whether to do the same for apr_interval_time_t.
I'm not really comfortable doing a change like this without changing
the name for apr_time_t. If we are going to change the semantics
we need to create a new identifier.
-aaron
interval times Re: watch out for thread_cond_timedwait problems
Posted by Brian Pane <br...@apache.org>.
William A. Rowe, Jr. wrote:
> #define apr_time_usec(time) ((apr_int32_t)((time) % APR_USEC_PER_SEC))
>
> which will take the big number's modulos before truncating to 32 bits.
Thanks. Speaking of the time_macros, I've only converted about
half of the instances of "time / APR_USEC_PER_SEC" in httpd-2.0
and APR to use to the macros. The other half are operations on
apr_interval_time_t, rather than apr_time_t.
If we change apr_time_t to use binary microseconds, we'll have to
decide whether to do the same for apr_interval_time_t.
I see strong points both for and against changing apr_interval_time_t:
- Interval times often are added to absolute times, so they should
use the same format as absolute times so the additions won't
produce unexpected errors.
- On the other hand, interval times often are used as arguments to
things like select calls, so they should use decimal microseconds
to prevent unexpected errors when a programmer says something like,
"I need my poll to block for 5 seconds at most, so I'll pass it a
timeout of 5,000,000."
Does anyone else have a strong opinion on whether interval times should
always use the same representation as apr_time_t?
Thanks,
--Brian
Re: watch out for thread_cond_timedwait problems
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 10:23 AM 7/2/2002, Brian Pane wrote:
>Do you get a correct tv_nsec if you remove the cast to 32-bit int
>in the apr_time_usec macro?
Yes and no... it isn't the cast (usec or nsec, for that matter, fit in a signed
32 bit integer.) It was the order of evaluation;
>-#define apr_time_usec(time) ((apr_int32_t)(time) % APR_USEC_PER_SEC)
>+#define apr_time_usec(time) ((time) % APR_USEC_PER_SEC)
This isn't the right solution, IMHO. I just committed this;
#define apr_time_usec(time) ((apr_int32_t)((time) % APR_USEC_PER_SEC))
which will take the big number's modulos before truncating to 32 bits.
RE: watch out for thread_cond_timedwait problems
Posted by Ryan Bloom <rb...@covalent.net>.
> From: Brian Pane [mailto:bpane@pacbell.net]
> On Tue, 2002-07-02 at 08:01, Jeff Trawick wrote:
> > Jeff Trawick <tr...@attglobal.net> writes:
> >
> > > I dunno what the cause is yet, but I'm getting testlock failures
for
> > > the last day or so.
> > >
> > > Tru64:
> > >
> > > thread_cond_timedwait Tests
> > > Initializing the first apr_thread_mutex_t OK
> > > Initializing the apr_thread_cond_t OK
> > > Waiting for condition for 5 seconds
Failed!
> (bad timer)
> > > stderr:
> > > thread_cond_timedwait test failed : [22] Invalid argument
> >
> > (dbx) n
> > thread 0xc [apr_thread_cond_timedwait:139 ,0x3ffbfff21fc]
> > Source not available
> > (dbx) p abstime
> > struct {
> > tv_sec = 1025619886
> > tv_nsec = -453280000
> > }
> > (dbx)
>
> Do you get a correct tv_nsec if you remove the cast to 32-bit int
> in the apr_time_usec macro?
It used to be that we all pretty much accepted that Apache rarely ever
casted variables. The general rule was that if a variable required a
cast, you most likely had a bigger problem someplace.
Can we please try to get back to NOT casting variables.
Ryan
Re: watch out for thread_cond_timedwait problems
Posted by Brian Pane <bp...@pacbell.net>.
On Tue, 2002-07-02 at 08:01, Jeff Trawick wrote:
> Jeff Trawick <tr...@attglobal.net> writes:
>
> > I dunno what the cause is yet, but I'm getting testlock failures for
> > the last day or so.
> >
> > Tru64:
> >
> > thread_cond_timedwait Tests
> > Initializing the first apr_thread_mutex_t OK
> > Initializing the apr_thread_cond_t OK
> > Waiting for condition for 5 seconds Failed! (bad timer)
> > stderr:
> > thread_cond_timedwait test failed : [22] Invalid argument
>
> (dbx) n
> thread 0xc [apr_thread_cond_timedwait:139 ,0x3ffbfff21fc]
> Source not available
> (dbx) p abstime
> struct {
> tv_sec = 1025619886
> tv_nsec = -453280000
> }
> (dbx)
Do you get a correct tv_nsec if you remove the cast to 32-bit int
in the apr_time_usec macro?
--Brian
Index: apr/include/apr_time.h
===================================================================
RCS file: /home/cvs/apr/include/apr_time.h,v
retrieving revision 1.53
diff -u -r1.53 apr_time.h
--- apr/include/apr_time.h 12 Jun 2002 22:23:56 -0000 1.53
+++ apr/include/apr_time.h 2 Jul 2002 15:21:05 -0000
@@ -95,7 +95,7 @@
/** number of microseconds per second */
#define APR_USEC_PER_SEC APR_TIME_C(1000000)
-#define apr_time_usec(time) ((apr_int32_t)(time) % APR_USEC_PER_SEC)
+#define apr_time_usec(time) ((time) % APR_USEC_PER_SEC)
#define apr_time_sec(time) ((apr_int64_t)(time) / APR_USEC_PER_SEC)
Re: watch out for thread_cond_timedwait problems
Posted by Jeff Trawick <tr...@attglobal.net>.
Jeff Trawick <tr...@attglobal.net> writes:
> I dunno what the cause is yet, but I'm getting testlock failures for
> the last day or so.
>
> Tru64:
>
> thread_cond_timedwait Tests
> Initializing the first apr_thread_mutex_t OK
> Initializing the apr_thread_cond_t OK
> Waiting for condition for 5 seconds Failed! (bad timer)
> stderr:
> thread_cond_timedwait test failed : [22] Invalid argument
(dbx) n
thread 0xc [apr_thread_cond_timedwait:139 ,0x3ffbfff21fc]
Source not available
(dbx) p abstime
struct {
tv_sec = 1025619886
tv_nsec = -453280000
}
(dbx)
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: watch out for thread_cond_timedwait problems
Posted by Brian Pane <bp...@pacbell.net>.
On Tue, 2002-07-02 at 06:39, Jeff Trawick wrote:
> I dunno what the cause is yet, but I'm getting testlock failures for
> the last day or so.
I made one recent change to apr_thread_cond_timedwait():
@@ -133,8 +133,8 @@
struct timespec abstime;
then = apr_time_now() + timeout;
- abstime.tv_sec = then / APR_USEC_PER_SEC;
- abstime.tv_nsec = (then % APR_USEC_PER_SEC) * 1000; /* nanoseconds
*/
+ abstime.tv_sec = apr_time_sec(then);
+ abstime.tv_nsec = apr_time_usec(then) * 1000; /* nanoseconds */
rv = pthread_cond_timedwait(cond->cond, &mutex->mutex, &abstime);
#ifdef PTHREAD_SETS_ERRNO
The new version should be equivalent to the old one, unless the
cast to apr_int32_t in apr_time_usec is causing problems on 64-bit
platforms.
--Brian