You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by David Jones <os...@gmail.com> on 2007/10/12 20:53:49 UTC
PATCH: apr/locks/unix/thread_cond.c
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;
Re: PATCH: apr/locks/unix/thread_cond.c
Posted by David Jones <os...@gmail.com>.
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 <os...@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. <wr...@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;
> >
> >
>
Re: PATCH: apr/locks/unix/thread_cond.c
Posted by David Jones <os...@gmail.com>.
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. <wr...@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;
>
>
Re: PATCH: apr/locks/unix/thread_cond.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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;