Is there a feature macro for cross-process-capable atomics?

[Jacob Champion]

Hi all,

I'd like to be able to use the apr_atomic primitives for cross-process 
work in shared memory, but as far as I can see, not every implementation 
is guaranteed to work across processes (for example, the generic 
implementation uses apr_thread_mutex*).


I'd be fine falling back to a heavyweight implementation if a platform 
truly needed it, but I can't find a way to "query" characteristics of 
the atomics implementation, so the fallback unfortunately has to be the 
default. Is there a feature macro I'm missing somewhere?


--Jacob

Re: svn commit: r1797267 - in /apr/apr/branches/1.6.x: CHANGES locks/beos/proc_mutex.c locks/netware/proc_mutex.c locks/os2/proc_mutex.c locks/win32/proc_mutex.c

[Yann Ylavic]

On Thu, Jun 1, 2017 at 11:10 PM,   wrote:
> Author: wrowe
> Date: Thu Jun  1 21:10:38 2017
> New Revision: 1797267
>
> URL: http://svn.apache.org/viewvc?rev=1797267=rev
> Log:
> Partially revert 1738806 (r1733775, r1738791 from trunk), preserve
> apr_os_proc_mutex_get_ex|_put_ex, but fall back to the supported
> APR_LOCK_DEFAULT
[]
>
> Modified: apr/apr/branches/1.6.x/locks/os2/proc_mutex.c
> URL: 
> http://svn.apache.org/viewvc/apr/apr/branches/1.6.x/locks/os2/proc_mutex.c?rev=1797267=1797266=1797267=diff
> ==
> --- apr/apr/branches/1.6.x/locks/os2/proc_mutex.c (original)
> +++ apr/apr/branches/1.6.x/locks/os2/proc_mutex.c Thu Jun  1 21:10:38 2017
> @@ -62,7 +62,7 @@ APR_DECLARE(const char *) apr_proc_mutex
>
>  APR_DECLARE(apr_lockmech_e) apr_proc_mutex_mech(apr_proc_mutex_t *mutex)
>  {
> -return APR_LOCK_DEFAULT_TIMED;
> +return APR_LOCK_DEFAULT;
>  }
>
>  APR_DECLARE(const char *) apr_proc_mutex_name(apr_proc_mutex_t *mutex)
> @@ -218,7 +218,7 @@ APR_DECLARE(apr_status_t) apr_os_proc_mu
>  {
>  *ospmutex = pmutex->hMutex;
>  if (mech) {
> -*mech = APR_LOCK_DEFAULT_TIMED;
> +return *mech = APR_LOCK_DEFAULT;

return?

>  }
>  return APR_SUCCESS;
>  }

Re: [VOTE] Release APR-1.6.1 and APR-UTIL 1.6.0

[William A Rowe Jr]

On Wed, May 31, 2017 at 5:24 PM, William A Rowe Jr  wrote:
> Greg and others... (Netware, Win32, OS2, BEOS), please have a look
> at the attached patch, which should apply to the 1.6.1 candidate.

Committed, review on Netware, OS2 and BEOS would still be appreciated,
either the candidate+patch or simply fetch 1.6.x branch.

lockmech ambiguity (Was: Release _timedlock API in 1.6.x?)

[William A Rowe Jr]

On Mon, May 22, 2017 at 3:22 PM, Yann Ylavic  wrote:
>
> From an API perspective, the single timeout argument looks consensual.
> So there may still be some bug(s) somewhere, which we would fix as
> always, but it would unlikely break existing applications since it's
> new feature, hence my positive vote...

I'm quite confused in retrospect with the apr_lockmech_e logic
as it exists in the 'oddball' architectures and the enum values.

APR_LOCK_DEFAULT looks to be the correct answer on the
oddball architectures. When we do an apr_os_proc_mutex_get_ex
we want to know what sort of void* object was just returned to us.
So long as the underlying lock object type didn't change (which it
doesn't appear to do so on the single-mutex-style architectures),
the right answer seems to remain APR_LOCK_DEFAULT.

APR_LOCK_DEFAULT_TIMED seems to express the desire to
have a lock mech that can be timed. But the underlying system
object doesn't vary, right? So apr should still report that it is one
APR_LOCK_DEFAULT. This could have been broken down into
explicit WIN32, NETWARE, BEOSSEM types. That seems like
an apr 2.0 change if we want it to happen.

As a short-term hack on these architectures, defining the enum
value of APR_LOCK_DEFAULT_TIMED as identical to the
APR_LOCK_DEFAULT value, both IsKindOf tests and the OS
datatype handling would remain correct, right?

On Unix, the problem in 1.7.x is broader... since a number of the
lockmech can be timed locks (and a number cannot). Again,
having retrieved the apr_os_proc_mutex, we need to know which
API handles it, not whether it is APR_LOCK_DEFAULT[_TIMED].
We might -also- want to know whether it is the default, and
whether it supported timed attempts (but if you know the API,
you know if there are timeouts available.)

Seems we heavily overloaded the recent timedlock and lockmech
changes to try to accomplish multiple purposes which are at odds
with one another, and need to mop this up before we can declare
1.7.x baked.

> PS: really sorry for the delay and the lack of activity these days, I
> had so few spare times...

Understandable, please give this some consideration when you
have cycles!

Re: [VOTE] Release APR-1.6.1 and APR-UTIL 1.6.0

[Gregg Smith]

That works for me on Windows.
Thanks.


On 5/31/2017 3:24 PM, William A Rowe Jr wrote:

Greg and others... (Netware, Win32, OS2, BEOS), please have a look
at the attached patch, which should apply to the 1.6.1 candidate.

It suggests several fixes are needed on 1.7.x branch as well, because
retrieving the lockmeth should succeed on Netware (and the answer
is always APR_LOCK_DEFAULT, on all these architectures.) Other
values on the create or put call must return failure.

Please let us know your results so that I can commit.




On Wed, May 31, 2017 at 2:15 PM, William A Rowe Jr  wrote:

Investigating which commit may have been missed... Update within the hour.

On May 31, 2017 1:44 PM, "Gregg Smith"  wrote:


Something tells me not everything of timelock got ripped out.

 cl.exe /nologo /MD /W3 /Zi /O2 /Oy- /I "./include" /I
"./include/arch" /I "./include/arch/wi
n32" /I "./include/arch/unix" /D "NDEBUG" /D "APR_DECLARE_STATIC" /D
"WIN32" /D "WINNT" /D "_WINDOWS
" /Fo".\LibR\\" /Fd".\LibR\apr-1" /FD /c .\locks\win32\proc_mutex.c
proc_mutex.c
.\locks\win32\proc_mutex.c(46): error C2065: 'APR_LOCK_DEFAULT_TIMED':
undeclared identifier


As often happens in mixed-purpose overloaded commits, this one needs to be
backed out in pieces with a number of them retained;


r1738806 | ylavic | 2016-04-12 09:16:40 -0500 (Tue, 12 Apr 2016) | 26 lines

Merge r1733775, r1738791 from trunk:


apr_proc/global_mutex: Fix API regarding the native OS mutexes
accessors from/to available APR mechanisms, adding the new functions
apr_os_proc_mutex_get_ex() and apr_os_proc_mutex_set_ex() which give
control to the user over the selected mechanisms, including the missing
POSIX semaphores (sem_t) on platforms supporting them.

For POSIX sems, this moves the "sem_t *psem_interproc;" member from struct
apr_proc_mutex_t to apr_os_proc_mutex_t (now complete) so that we can avoid
members duplication between the two structs, and hence replace all the doublons
in apr_os_proc_mutex_t with an apr_os_proc_mutex_t member, called "os", to be
used for runtime.

This first commit aims to be backportable to 1.6.x, thus does not address the
Netware case which requires an incompatible change of the apr_proc_mutex_t to
a pointer type (the implementation is here since very similar to other changes
is this commit, but it is commented out for now, a simple follow up is coming
with the type change for trunk only...).


proc_mutex-unix: follow up to r1733775.
Restore mmap-ed fd close stripped by above commit.

Re: lockmech ambiguity (Was: Release _timedlock API in 1.6.x?)

[Yann Ylavic]

Hi Bill,

On Thu, Jun 1, 2017 at 6:32 PM, William A Rowe Jr  wrote:
> On Mon, May 22, 2017 at 3:22 PM, Yann Ylavic  wrote:
>>
>> From an API perspective, the single timeout argument looks consensual.
>> So there may still be some bug(s) somewhere, which we would fix as
>> always, but it would unlikely break existing applications since it's
>> new feature, hence my positive vote...
>
> I'm quite confused in retrospect with the apr_lockmech_e logic
> as it exists in the 'oddball' architectures and the enum values.
>
> APR_LOCK_DEFAULT looks to be the correct answer on the
> oddball architectures. When we do an apr_os_proc_mutex_get_ex
> we want to know what sort of void* object was just returned to us.
> So long as the underlying lock object type didn't change (which it
> doesn't appear to do so on the single-mutex-style architectures),
> the right answer seems to remain APR_LOCK_DEFAULT.
>
> APR_LOCK_DEFAULT_TIMED seems to express the desire to
> have a lock mech that can be timed. But the underlying system
> object doesn't vary, right? So apr should still report that it is one
> APR_LOCK_DEFAULT. This could have been broken down into
> explicit WIN32, NETWARE, BEOSSEM types. That seems like
> an apr 2.0 change if we want it to happen.

APR_LOCK_DEFAULT_TIMED is a whish for apr_proc_mutex_create() or/and
apr_os_proc_mutex_set_ex(), but also (and soncequently) a capability
of the underlying OS mutex.

For non-unixes mutexes, appart from Netware, the underlying OS mutex
can be apr_proc_mutex_timedlock()ed natively so why wouldn't we
announce it as APR_LOCK_DEFAULT_TIMED?

For Netware, we could create the associated condvar at
apr_os_proc_mutex_set_ex() time if we also wanted to make it
APR_LOCK_DEFAULT_TIMED, but I didn't spend too much time on Netware
(and couldn't test anything...).
Anyway, Netware proc mutexes are APR_LOCK_DEFAULT still.

>
> As a short-term hack on these architectures, defining the enum
> value of APR_LOCK_DEFAULT_TIMED as identical to the
> APR_LOCK_DEFAULT value, both IsKindOf tests and the OS
> datatype handling would remain correct, right?

So yes, I think that for OSes which have a single mech which is TIMED
natively we should APR_LOCK_DEFAULT_TIMED = APR_LOCK_DEFAULT, makes
sense and avoids breaking existing APR_LOCK_DEFAULT usages.

>
> On Unix, the problem in 1.7.x is broader... since a number of the
> lockmech can be timed locks (and a number cannot). Again,
> having retrieved the apr_os_proc_mutex, we need to know which
> API handles it, not whether it is APR_LOCK_DEFAULT[_TIMED].

This is the case actually, apr_os_proc_mutex_get_ex() returns
mutex->method->mech, which is the real mech.

> We might -also- want to know whether it is the default, and
> whether it supported timed attempts (but if you know the API,
> you know if there are timeouts available.)

There could be a (some) helper(s) for that.

>
> Seems we heavily overloaded the recent timedlock and lockmech
> changes to try to accomplish multiple purposes which are at odds
> with one another, and need to mop this up before we can declare
> 1.7.x baked.

I don't find it odd, still, and personally I prefer a ENOTIMPL when
APR_LOCK_DEFAULT_TIMED is asked than a spinning fallback (which could
be implemented externally), but given that we choose to fallback in
previous discussions, but after APR_LOCK_DEFAULT_TIMED was introduced,
maybe we don't need it anymore and it should be axed (we'd still need
a way to ask for the best *timed* mech though...).