apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: watch out for thread_cond_timedwait problems
Date Thu, 27 Jun 2002 18:53:45 GMT
> From: Brian Pane [mailto:bpane@pacbell.net]
> On Tue, 2002-07-02 at 08:01, Jeff Trawick wrote:
> > Jeff Trawick <trawick@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



Mime
View raw message