On Tue, Oct 22, 2013 at 9:31 PM, William A. Rowe Jr. <wrowe@rowe-clan.net> wrote:
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.

There's no technical reason why unprivileged callers can't use non-anonymous shared memory segments on Windows, just as on Unix.  Some apr programs (more specifically, some modules for httpd) developed and tested on Unix assume that you can do so, and I don't see the benefit of chasing after that for no real benefit other than avoiding an APR limitation.  It isn't hard at all to conceive of a multi-process application which would require non-anonymous shared memory segments to operate, with no necessity (and thus no good reason) to create them in the global namespace, irrespective of privilege.  And lastly there is testshm, which could be quieted by other means, though without exercising the non-anonymous path nearly so often.


Irrespective of the original thought around non-anonymous, it looks like the Global NS use was a pragmatic solution for the change in Win2K SPn which necessarily introduced surprising semantics into this corner of APR, and while the change worked for some common scenarios it left others in the dust.

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