apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jones" <oscare...@gmail.com>
Subject Re: PATCH: apr/locks/unix/thread_cond.c
Date Wed, 19 Dec 2007 16:28:50 GMT
Tweaked patch to build ontop of revision 596402 and put the change inside
the ifdef HAVE_ZOS_PTHREADS, so we don't  need the __MVS__ specific ifdef.

Index: locks/unix/thread_cond.c
===================================================================
--- locks/unix/thread_cond.c    (revision 605600)
+++ locks/unix/thread_cond.c    (working copy)
@@ -30,6 +30,9 @@
 #ifdef HAVE_ZOS_PTHREADS
     if (rv) {
         rv = errno;
+        if (EAGAIN == rv) {
+            return APR_TIMEUP;
+        }
     }
 #endif
     return rv;


On Oct 16, 2007 9:58 AM, David Jones <oscaremma@gmail.com> wrote:

> i've added both rc's to the MVS leg. testall/testlock passes.
>
> From the following zOS C/C++ run time manual snippet, looks like this
> should be enough.
>
> 3.563 pthread_cond_timedwait() -- Wait on a Condition Variable
>
> | If unsuccessful, *pthread_cond_timedwait*() returns -1 and sets errno to
> one
> | of the following values:
>
>
> | EAGAIN
> For a private condition variable, the time specified by abstime
> | has passed.
>
>
> | EINVAL
> Can be one of the following error conditions:
>
>
>    - | The value specified by cond is not valid.
>    - | The value specified by mutex is not valid.
>    - | The value specified by abstime (tv_sec) is not valid.
>    - | The value specified by abstime (tv_nsec) is not valid.
>    - | Different mutexes were specified for concurrent operations
>    | on the same condition variable.
>    - | The mutex is not owned by the current thread.
>
>
>
> | ETIMEDOUT
> For a shared condition variable, the time specified by abstime
> | has passed.
>
>
> Index: locks/unix/thread_cond.c
> ===================================================================
> --- locks/unix/thread_cond.c    (revision 579232)
> +++ locks/unix/thread_cond.c    (working copy)
> @@ -92,7 +92,11 @@
>          rv = errno;
>      }
>  #endif
> +#ifdef __MVS__
> +    if (ETIMEDOUT == rv || EAGAIN == rv) {
> +#else
>      if (ETIMEDOUT == rv) {
> +#endif /* __MVS__ */
>          return APR_TIMEUP;
>      }
>      return rv;
>
>
>
> On 10/12/07, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> >
> > This looks a little bit dangerous.  Aren't there two legitimate cases
> > of EAGAIN?  The timed-out, but also that it was interrupted?
> >
> > Is there any way to disambiguate these?
> >
> > Bill
> >
> > David Jones wrote:
> > > pthread_cond_timedwait on zOS returns EAGAIN,  not ETIMEDOUT as on
> > other
> > > unix platforms.
> > > Change apr_thread_cond_timedwait to check platform and rv when
> > deciding
> > > to return APR_TIMEUP.
> > > I didn't add any config for the zOS rv , as it didn't seem to add
> > anything.
> > >
> > > apr/testall testlock  test_timeoutcond will pass with this change, it
> > > does not currently.
> > >
> > >
> > >
> > >
> > > Index: thread_cond.c
> > > ===================================================================
> > > --- thread_cond.c       (revision 579232)
> > > +++ thread_cond.c       (working copy)
> > > @@ -92,7 +92,11 @@
> > >          rv = errno;
> > >      }
> > >  #endif
> > > +#ifdef __MVS__
> > > +    if (EAGAIN == rv) {
> > > +#else
> > >      if (ETIMEDOUT == rv) {
> > > +#endif /* __MVS__ */
> > >          return APR_TIMEUP;
> > >      }
> > >      return rv;
> >
> >
>

Mime
View raw message