apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: svn commit: r1797413 - /apr/apr/branches/1.6.x/locks/netware/proc_mutex.c
Date Mon, 05 Jun 2017 20:33:02 GMT
On Mon, Jun 5, 2017 at 6:07 PM, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
> On Jun 3, 2017 13:36, "Yann Ylavic" <ylavic.dev@gmail.com> wrote:
>
>
>  #if 0
>      /* We need to change apr_os_proc_mutex_t to a pointer type
>       * to be able to implement this function.
> @@ -141,6 +138,11 @@ APR_DECLARE(apr_status_t) apr_os_proc_mutex_get_ex
>          *mech = APR_LOCK_DEFAULT;
>      }
>      return APR_SUCCESS;
> +#else
> +    /* ENOTIMPL could be more meaningful, ENOLOCK is what 1.x has
> +     * always returned... From 2.x, the API issue is fixed.
> +     */
> +    return APR_ENOLOCK;
>  #endif
>  }
>
>
> Can I challenge your assumpion here for 1.7.x?
>
> You are reading a change in apr_proc_mutex_t and apr_os_proc_mutex_t as a
> binary breaking change.

I didn't that feel this change :
-typedef NXMutex_t  apr_os_proc_mutex_t;
+typedef NXMutex_t* apr_os_proc_mutex_t;
was a "minor" change.

>
> But if you consider that apr's type is opaque, and that the underlying
> system apr_os_proc_mutex_t could not be _get or _set through 1.6.x, then the
> apr_os_proc_mutex_t on Netware was simply unused.

But I'd like to concur to this point of view!

> Is there an actual
> versioning conflict correcting the type declaration on Netware so these work
> from 1.7.0 forwards?

What do you mean by "versioning conflict"?
If everyone is fine with the above type change (which can only fix
things, I don't see either how current apr_os_proc_mutex_t on netware
can be used), I'm very much for it to go to 1.7 (and even 1.6, why
not?)...

Mime
View raw message