Joe Orton <[EMAIL PROTECTED]> wrote:
> > But the two systems work in completely different ways. The main
> > problem I was having, was that when an apache process is forcibly killed, it
> > has no way to tell the OS that the shared memory is no longer needed. Then
> > when it restarts, SysV IPC is still holding onto the memory so
> > apr_shm_create fails.
>
> Two points to note here: apr_shm_remove() was added in APR 1.0 which
> somewhat mitigates the problem: but really it sounds like you should be
> using anonymous shm (pass a NULL filename to apr_shm_create). At least
> some of the anon shm implementations give the behaviour you're
> expecting.
If I was working exclusively within apache, that'd be fine, but
other software may want to manipulate the tracker's state as well (eg; at
least one of my users has a command line app written using
Net::BitTorrent::LibBTT to administer a running tracker).
What I want:
- A process that knows it's supposed to be a master issues a create,
all others issue an attach
- When the last process touching the memory dies, it goes away.
- To support concurrent operations on the same box, the identifier
for the shared memory segment should be configurable and usable as a command
line option, etc. in utility programs.
I can achieve this behaviour using mmap() and checking /proc/*/fd/*
under linux, but that isn't portable. :-)
> IIRC the logic for choice of name-based shm implementation for APR does
> exactly match that of MM - is that not true? I don't know why shmget is
> preferred over mmap in this case. For anonymous shm, mmap/MAP_ANON is
> indeed preferred over shmget, which does seem inconsistent.
All I know for sure is that when I was using libmm's mm_create, I
could kill -9 the server as many times as I wanted and when I restarted, it
got a fresh memory segment, but since using apr_shm_create, it collides with
the memory that was allocated by the dead process.
- Tyler
