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 Wed, 23 Oct 2013 02:08:43 GMT
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

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

View raw message