apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tyler MacDonald <ty...@yi.org>
Subject Shared memory segment management
Date Tue, 18 Apr 2006 20:39:54 GMT
Hello,

	I opened a bug via the debian bug tracking system awhile ago:

	http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256109

	AFAIK it never got forwarded upstream. Since then, I've discovered
this great thing called email so I can contact you guys directly. ;-)

	The problem is/was that APR's implementation of "portable" shared
memory falls back on one of several different shared memory implementations,
which have different operating patterns. Under linux, it seems to default to
System V IPC; if that fails, it falls back on other implementations, one of
which is mmap().

	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.

	I see Dominique Quatravaux has emailed you guys about this once
already, but it doesnt look like he got a reply:

	http://marc.theaimsgroup.com/?l=apr-dev&m=110719155629159&w=2

	Looking at the configure.in for APR distributed with Apache 2.2, it
looks like SysV IPC is still the choice preferred by APR, even though this
creates an obvious behavioural difference for the same code running against
APR on operating systems that have SysV IPC and operating systems that
don't. 

	Has there been any further discussion among the APR developers about
this? Why is SysV IPC the "preferred" choice in the first place? For the
behaviour I want (shared memory goes away when creating process dies) is
there a better implementation available using APR, or will I be forced to
bring another library into the mix, such as libmm?

	Thanks,
		Tyler


Mime
View raw message