apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: cvs commit: apr/locks/netware thread_rwlock.c thread_mutex.c thread_cond.c
Date Thu, 11 Oct 2001 22:14:22 GMT
On Thursday 11 October 2001 02:36 pm, Aaron Bannert wrote:
> On Thu, Oct 04, 2001 at 03:23:00PM -0700, Ryan Bloom wrote:
> > On Thursday 04 October 2001 02:37 pm, Aaron Bannert wrote:
> > > On Thu, Oct 04, 2001 at 03:34:23PM -0600, Brad Nicholes wrote:
> > > > As I was implementing the apr_thread_cond_*() functions it appears
> > > > that we are missing one function.  I propose that we add the
> > > > following function:
> > > >
> > > > APR_DECLARE(apr_status_t) apr_thread_cond_timedwait(apr_thread_cond_t
> > > > *cond, apr_thread_mutex_t *mutex,  unsigned long interval);
> > > >
> > > >
> > > > What do you think??
> > >
> > > If it can be implemented reliably on all of the platforms, I'm all for
> > > it. I'll even write the patch for the stubs. Can we get some
> > > reassurance that it'll work out on: beos, os2/win32?
> >
> > I can make it work on win32.
>
> cool.
>
> Two questions:
>
> - What about OS/2 and Beos? (I know David is nursing his RSI, but what
>   about OS/2?)

I would bet that it is portable, go ahead and create the API.

> - How should we handle the timeout, as an offset or absolute, and in
>   what units?  POSIX uses "const struct timespec *abstime" but that will
>   work with Brad's proposal above too.

The timeout should be handled just like all other timeouts in APR, namely
the number of microseconds until it should pop.

Ryan

______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Mime
View raw message