apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Quatravaux <...@kilimandjaro.dyndns.org>
Subject [PATCH] APR should prefer mmap() to shmat() whenever possible
Date Mon, 31 Jan 2005 17:14:51 GMT
Dear APR developers,

Like a couple of random folks on the great Internet 
I've been unsuccessfully trying to use a ScoreBoardFile with Apache 
2.0.52 under Linux (Debian testing). Symptoms are:

    * your usual SysV IPC leakage, which prevents me from restarting the
      server (I *did* shutdown Apache with care and SIGTERM);
    * the ScoreBoard does not actually contain a scoreboard, only what
      looks like a rendez-vous into the allocated SysV shared memory
      segment. (I would love to be able to parse the scoreboard file
      from Perl as I did with Apache 1.3, without resorting to some
      weirdo SysV-shm CPAN wrappage).

Tracing the problem back, I found that in my libapr configuration, I have

#define APR_USE_SHMEM_SHMGET       1

(the rest of APR_USE_SHMEM_* being 0 - this seems to be the normal 
outcome for Linux as one of the aforementioned folks had the same thing 
under RedHat), and this in turn is because apr/trunk/configure.in (fresh 
from Subversion, around line 801) prefers "SysV IPC shmget()" over 
"Classical mmap() on temporary file", which is the *worse* option in 
configure.in's view (according to a comment way below, at line 1631).

Now, why on earth would one prefer SysV shared memory over file-based 
mmap() when both are available? At the very least this should be made a 
command-line configuration option, for the benefit of distribution 
maintainers who want to get rid of SysV stuff altogether. Enclosed is a 
patch to configure.in that sets mmap-first behavior (w/o a command-line 
switch), and shuffles the documentation around a bit so as to avoid 
future confusion on this topic.

Best regards and thanks for all the hard work,

<< Tout n'y est pas parfait, mais on y honore certainement les jardiniers >>

			Dominique Quatravaux <dom@kilimandjaro.dyndns.org>

View raw message