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: [EMAIL PROTECTED]
