On Thursday, February 20, 2014 at 1:25:46 AM UTC-5, David McCurley wrote: > > OTOH, groupcache has neither cache invalidation (one of the "three" hard >> problems in computer science) nor value updating, which keeps its >> implementation considerably simpler and enables a key feature. AFAICT, this >> is the main reason for it being said that it is "a replacement for >> memcached /in many cases/" (emphasis mine). In practice though, this isn't >> anything that can't be taken care of in application code by careful key >> formulation. >> > > In Unix (and Linux), we used to* atomically "mv" a new binary or library into place, and the OS would garbage-collect the old one's disk blocks when there were no remaining references to it.
If I add a datestamp or other versiuon identifier to the groupcache key, I get the same behavior. Old clients use the old copy, new ones use the new copy, and old copies get flushed out / garbage collected when no-one's using them. --dave [* many folks have forgotten this] -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
