apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: [PATCH] "Global" vs. "Local" prefix on named mutexes and named shm on Windows
Date Tue, 15 Oct 2013 10:47:35 GMT
On Tue, Oct 15, 2013 at 1:01 AM, Mladen Turk <mturk@apache.org> wrote:

> On 10/15/2013 02:27 AM, Jeff Trawick wrote:
>> Or in a more APR-like fashion, add apr_shm_create_ex() and
>> apr_shm_attach_ex() which have a special processing flag (bitmap).  For
>> Windows,  APR_SHM_NS_LOCAL and APR_SHM_NS_GLOBAL would be respected.  That
>> could be used by an app that can't with with APR's
>> imperfect attempts to manage global vs. local.  I don't think there is a
>> perfect anyway.
>> As 1.5.x hasn't been released yet, the _ex() functions could be in it.
> Replacing Global with Local would basically limit the apr_shm API and it
> won't
> allow IPC using shm across sessions. With services running in Session0 shm
> is one
> of the effective IPC mechanisms. Using _ex() api and making _create() and
> _attach()
> as macros should do the trick. Although not sure what should be default
> (global or local)
> I'd go for backward compatibility (no sudden surprises when changing
> version)

Yeah (backward compatibility); specifying APR_SHM_NS_LOCAL or _GLOBAL would
bypass the current logic in trunk.  I still like the heuristic that allows
non-privileged processes to collaborate via shared memory without adding
any platform-specific flags.  The flag would be needed if an app wants to
use Local even if the process might be privileged, or an app must use
Global to operate (and fail if it is not privileged).

> Regards
> --
> ^TM

Born in Roswell... married an alien...

View raw message