[PATCH] memcached on FreeBSD...

[Sean Chittenden]

Howdy.  When are you guys planning on releasing 1.1.9?  Many of the
patches used by the port have already been applied or worked around.
I couldn't get CVS to build though.  What version of autofuck are you
guys depending on?  I couldn't get it to build with 213, 253, or 257
(need to copy in install.sh or install-sh too, btw).

% autoconf257
configure.ac:5: error: possibly undefined macro: AM_INIT_AUTOMAKE
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:6: error: possibly undefined macro: AM_CONFIG_HEADER
% cp /usr/src/crypto/openssl/util/install.sh .
% ./configure --with-libevent=/usr/local/lib --prefix=/usr/local
configure: error: cannot run /usr/local/bin/bash ./config.sub



For 1.1.8, I had to gut the -k option since that's a Linux-ism (though
I noticed the #ifdef's around the mlockall() calls in CVS).  Has any
thought been given to using mmap(2) instead malloc(3)?  OSes are
generally much better about actually free()ing data back to the OS if
it's been mmap(2)'ed instead of using sbrk(2) (what most malloc(3)
calls use internally).  If you decide to mmap(2) non-anonymous files
you could get a persistent cache almost for free by mmap(2)'ing actual
files (of the hash ID of the objects?) and then use MAP_SHARED |
MAP_NOCORE | MAP_NOSYNC.  thttpd has a nifty mmap(2) cache that may be
worth peaking at if this is of interest (thttpd/mmc.[ch]).  Caching
aside, mmap(2) should have more portable locking semantics via
mlock(2) and can be friendlier on the VM if madvise(2) is used too.
mmap(2) and friends are from the BSD 4.4 spec and are likely POSIX or
SUSv3 calls at this point.  With Apache making heavy use of these
calls, I can't imagine an OS not supporting them in this day and age.

Just a design thought.

-sc

-- 
Sean Chittenden