On Tue, 15 Oct 2013 06:47:35 -0400
Jeff Trawick <firstname.lastname@example.org> wrote:
> On Tue, Oct 15, 2013 at 1:01 AM, Mladen Turk <email@example.com> wrote:
> > Replacing Global with Local would basically limit the apr_shm APII'm not a fan of causing tests to succeed when they mask a failure.
> > 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
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.