apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm MacCarthaigh <c...@stdlib.net>
Subject Re: svn commit: r329089 - in /apr/apr-util/trunk: build.conf include/apr_memcache.h memcache/ memcache/apr_memcache.c
Date Sat, 29 Oct 2005 09:15:36 GMT
On Fri, Oct 28, 2005 at 04:34:28PM -0500, William A. Rowe, Jr. wrote:
> So, we violate a basic apr design principal for an oddball service that we
> are seeking to support?  Or return APR_EINVAL when someone tries to set
> aside 10GB?  (This is a rather funny quibble when you consider how horrid
> using an external socket-cached data store to set aside 10GB for 'quick
> access' later on ;-)

.. or we split it into 2GB chunks with a small header and send them off, 
and do the converse on retrieval.

 memcache is a memory cache, and there are already platforms on which
more than 2GB (or even less) can't be stored contigously in memory. So
this seems like a portability problem the application will already have
hit. Moving around 2Gb linearly addressed chunks of memory is already
non-portable, no?

> FYI - why apr_memcache?  Unless it's either an in-memory cache, or some
> cache virtualized by page-fault retrieval, this is definately misnamed,
> or beholden to one oddball external project.

memcache is the name of the service:

	http://www.danga.com/memcached/

-- 
Colm MacCárthaigh                        Public Key: colm+pgp@stdlib.net

Mime
View raw message