Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <CACsi253sbJQNroNhr_nJPn=Ohd4V7unSuayYheTyyOD1e=tY7A@mail.gmail.com>
References: <CACsi253sbJQNroNhr_nJPn=Ohd4V7unSuayYheTyyOD1e=tY7A@mail.gmail.com>
From: William A Rowe Jr <wrowe@rowe-clan.net>
Date: Thu, 27 Jul 2017 10:43:26 -0500
Message-ID: <CACsi253QFxzWMAfY0wgSuEbxDSVC+5kZR4gmGo82Pm7i6K1Vvw@mail.gmail.com>
Subject: Re: Netware opinions requested; was Re: svn commit: r1797413
To: Yann Ylavic <ylavic.dev@gmail.com>, APR Developer List <dev@apr.apache.org>
Content-Type: text/plain; charset="UTF-8"
archived-at: Thu, 27 Jul 2017 15:43:38 -0000

We gave this two weeks... are any Netware users available to comment?

Otherwise, Yann, if we concur based on simple inspection, rather than
confirmation from the Netware developers, it seems this change should
go into apr 1.6.3 and a prominent NOTICE: added to CHANGES to
ensure Netware users that apr >= 1.6.3 should be combined with code
compiled to consume apr >= 1.6.3, or visa versa. If my reading is correct,
apr >= 1.6.3 with code compiled against an earlier apr will be suboptimal
but begin (suddenly) working. and the other two combinations, the API
simply results in a NOTIMPL result.

WDYT?

On Fri, Jul 14, 2017 at 11:18 AM, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
> On Mon, Jun 5, 2017 at 5:00 PM, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
>> On Mon, Jun 5, 2017 at 3:33 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
>>> 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"?
>>
>> As you noted some time ago in
>> http://git.net/ml/dev-apr-apache/2014-09/msg00057.html
>>
>> Ok... it seems I was confused, there is a * indirection in the
>> apr_os_proc_mutex_t arg of both _get and _put calls. Older
>> callers will dereference this to a 48 byte buffer, more than
>> enough to store a void *, and if the logic is simply a using
>> the _get result to _put into a new apr_proc_mutex_t, it will
>> just work. Recompiling the consuming code saves lots of
>> bytes and no other real change. Code compiled against
>> the new implementation but mis-invoked against the older
>> 1.5.x apr binary will deference a 4 byte buffer, but the older
>> apr *will not fill what it believed to be a 48 byte buffer*
>> because the _get and _put calls went unimplemented.
>>
>> Only code written to specifically use the NXMutex_t will
>> have problems, but any such code has never worked in
>> the first place.
>>
>>
>>> 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?)...
>>
>> If you are talking about simply fixing this defect for the untimed locks
>> I don't see a reason we can't just fix it in 1.6.x
>
> What do the Netware folks think? It appears to me that this can
> just be fixed for 1.6.3 without disrupting any use case on Netware.