~skeeto/public-inbox

1

Purgeable memory allocator

Rusty Conover
Details
Message ID
<CAPFu4vz+HKkrBbmyqnYwX5ptM0Nk-r+UDsWGL8UFGnJZjRUmPA@mail.gmail.com>
DKIM signature
pass
Download raw message
Hi Chris,

I've written an article about using the purgeable memory allocator
you've created in a redis/memcached caching context.  Please see it
at:

https://rusty.today/posts/thoughts-on-purgeable-caching

I'd be interested in hearing your opinion about locking subranges of a
large overall purgeable allocation.

Cheers,

Rusty
Details
Message ID
<20210104012752.x3d6u6bbe27rpqcd@nullprogram.com>
In-Reply-To
<CAPFu4vz+HKkrBbmyqnYwX5ptM0Nk-r+UDsWGL8UFGnJZjRUmPA@mail.gmail.com> (view parent)
DKIM signature
missing
Download raw message
Thanks for sharing your article, Rusty! Your list of downsides are all 
true and accurate.

> I'd be interested in hearing your opinion about locking subranges of a 
> large overall purgeable allocation.

If you're talking about adding this as a feature to my library, that 
implementation exists primarily as a proof of concept for my article, so 
outside of fixing defects I consider it frozen. The idea isn't that 
anyone would rely directly on my repository like a package. Instead, 
they would copy and embed it into their project, taking ownership of 
their fork — with the ubiquity of per-language package managers, a dying 
art these days — and making modifications if necessary to support that 
project. Or they would build their own using mine as a guide, e.g. when 
using something other than C.

If you're talking about the concept itself, the idea is sound. I can't 
think if any issues. It just requires a slightly more capable API — 
exactly the sort of local modification someone might need to make.
Reply to thread Export thread (mbox)