> "Christian" == Christian Jaeger <[EMAIL PROTECTED]> writes:
Christian> I haven't announced it on other forums (yet). (I think it's
Christian> more of a working version yet that needs feedback and some
Christian> work to make it generally useable (i.e. under
Christian> mod_perl). Which forum
At 20:37 Uhr -0400 4.9.2001, Geoffrey Young wrote:
>I remember the post and went to find IPC::FsSharevars a while ago and was
>un-intrigued when I didn't find it on CPAN. has there been any feedback
>from the normal perl module forums?
I haven't announced it on other forums (yet). (I think it's
> What about my IPC::FsSharevars? I've once mentioned it on this list,
> but I don't have the time to read all list mail, so maybe I've missed
> some conclusions following the discussion from last time.
I remember the post and went to find IPC::FsSharevars a while ago and was
un-intrigued when
> I don't think Cache::Cache has enough logic for an "atomic
> read-modify-write" in any of its modes to implement (for example) a
> web hit counter. It has only "atomic write". The "last write wins"
> strategy is fine for caching, but not for transacting, so I can see
> why Rob is a bit puzzled
> "Perrin" == Perrin Harkins <[EMAIL PROTECTED]> writes:
>> Uhh... good point, except that I don't trust the Cache code. The
>> AUTHOR isn't ready to put his stamp of approval on the
>> locking/updating.
Perrin> That sort of hesitancy is typical of CPAN. I wouldn't worry
Perrin> about it.
On Tue, Sep 04, 2001 at 12:14:52PM -0700, Rob Bloodgood wrote:
> ***OH WOW!*** So, DURING the course of composing this message, I've
> realized that the function expire_old_accounts() is now redundant!
> Cache::Cache takes care of that, both with expires_in and max_size. I'm
> leaving it in for
> > Uhh... good point, except that I don't trust the Cache code. The AUTHOR
> > isn't ready to put his stamp of approval on the locking/updating.
>
> That sort of hesitancy is typical of CPAN. I wouldn't worry about it. I
> think I remember Randal saying he helped a bit with that part. In my
>
> Uhh... good point, except that I don't trust the Cache code. The AUTHOR
> isn't ready to put his stamp of approval on the locking/updating.
That sort of hesitancy is typical of CPAN. I wouldn't worry about it. I
think I remember Randal saying he helped a bit with that part. In my
opinion, t
> > The _session_id is used as the seed for the locking semaphore.
> > *IF* I understood the requirements correctly, the _session_id has
> > to be the same FOR EVERY PROCESS in order for the locking to work
> > as desired, for a given shared data structure.
>
> Only if you want to lock the whole t
> Once upon a time, not many moons ago, the issue of Cache::Cache came up
with
> the SharedMemory Cache and the fact that it has NO locking semantics.
It does atomic updates. Do you really need more than that? The thread you
got this from was referring to checking out a piece of data, making a
> > One of the shiny golden nuggets I received from said slice was a
> > shared memory cache. It was simple, it was elegant, it was
> > perfect. It was also based on IPC::Shareable. GREAT idea. BAD
> > juju.
> Just use Cache::Cache. It's faster and easier.
Now, ya see...
Once upon a time, n
11 matches
Mail list logo
