apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: [PATCH] "Global" vs. "Local" prefix on named mutexes and named shm on Windows
Date Wed, 23 Oct 2013 01:31:05 GMT
On Tue, 15 Oct 2013 06:47:35 -0400
Jeff Trawick <trawick@gmail.com> wrote:

> On Tue, Oct 15, 2013 at 1:01 AM, Mladen Turk <mturk@apache.org> wrote:
> >>
> > 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).

I'm not a fan of causing tests to succeed when they mask a failure.

IIRC the non-anonymous apr_shm code was for sharing data between threads
and processes.  Moving this to \\Local\ on Win32 hides such flaws, but
doesn't serve to accomplish the goals of apr_shm, IMHO.

Can you offer a reason to support the \\Local\ shm space on win32?  I'm
all for functionality, but not to simply pass failing test cases.

View raw message