See attached for a patch that simply emulates that Mason-cache behaviour.
(Note that this does not fix the race conditions I identified in my
most-recent email to the list.)
-Toby
Perrin Harkins wrote:
On Thu, 2006-06-22 at 14:01 -0500, [EMAIL PROTECTED] wrote:
Or have the first hit after t
[EMAIL PROTECTED] ha scritto:
>
>
>
>
>
> [EMAIL PROTECTED] wrote on 06/23/2006 11:04:07 AM:
>
>> [EMAIL PROTECTED] ha scritto:
>>>
>>>
>>>
[EMAIL PROTECTED] ha scritto:
>
>
>> Perrin Harkins wrote:
>>> Toby Corkindale wrote:
One of the aims of my patch is to avo
[EMAIL PROTECTED] wrote on 06/23/2006 11:04:07 AM:
> [EMAIL PROTECTED] ha scritto:
> >
> >
> >
> >
> >> [EMAIL PROTECTED] ha scritto:
> >>>
> >>>
> >>>
> Perrin Harkins wrote:
> > Toby Corkindale wrote:
> >> One of the aims of my patch is to avoid the expense of having
> > numer
[EMAIL PROTECTED] ha scritto:
>
>
>
>
>> [EMAIL PROTECTED] ha scritto:
>>>
>>>
>>>
Perrin Harkins wrote:
> Toby Corkindale wrote:
>> One of the aims of my patch is to avoid the expense of having
> numerous
>> processes produce the same code simultaneously. So on the initial
>>>
> [EMAIL PROTECTED] ha scritto:
> >
> >
> >
> >
> >> Perrin Harkins wrote:
> >>> Toby Corkindale wrote:
> One of the aims of my patch is to avoid the expense of having
numerous
> >
> processes produce the same code simultaneously. So on the initial
> > bunch
> of requests, I'll
[EMAIL PROTECTED] ha scritto:
>
>
>
>
>> Perrin Harkins wrote:
>>> Toby Corkindale wrote:
One of the aims of my patch is to avoid the expense of having numerous
>
processes produce the same code simultaneously. So on the initial
> bunch
of requests, I'll still try and have the c
> Perrin Harkins wrote:
> > Toby Corkindale wrote:
> >> One of the aims of my patch is to avoid the expense of having numerous
> >> processes produce the same code simultaneously. So on the initial
bunch
> >> of requests, I'll still try and have the code delay all-but-one of
them
> >> from bu
Perrin Harkins wrote:
> Toby Corkindale wrote:
>> One of the aims of my patch is to avoid the expense of having numerous
>> processes produce the same code simultaneously. So on the initial bunch
>> of requests, I'll still try and have the code delay all-but-one of them
>> from building the page
Toby Corkindale wrote:
> One of the aims of my patch is to avoid the expense of having numerous
> processes produce the same code simultaneously. So on the initial bunch
> of requests, I'll still try and have the code delay all-but-one of them
> from building the page.
Presumably this only happ
Perrin Harkins wrote:
> Toby Corkindale wrote:
>> Perrin Harkins wrote:
>>> FYI, that's how Mason does it.
>> What is the behaviour for the first and second requests, before there is
>> *any* cached content available?
>
> In Mason? The same as any other request for un-cached content. You can
>
Toby Corkindale wrote:
> Perrin Harkins wrote:
>> FYI, that's how Mason does it.
>
> What is the behaviour for the first and second requests, before there is
> *any* cached content available?
In Mason? The same as any other request for un-cached content. You can
read the code and docs here:
h
Perrin Harkins wrote:
> On Thu, 2006-06-22 at 14:01 -0500, [EMAIL PROTECTED] wrote:
>> Or have the first hit after the expire set the expire time counter to the
>> next interval so the next hit does not even think to rebuild. Then you can
>> also rebuild the cache to a temp name and overwrite the
Matt S Trout wrote:
> Toby Corkindale wrote:
>> Hi,
>> There's a patch attached for Catalyst::Plugin::PageCache.
>> (It's not final, but more a "request for comments" on it so far. In
>> particular, some better way than using flock())
>
> Why not just use pid+tid and a cache key set/get to see if
[EMAIL PROTECTED] wrote:
>
>
>
>
>
>
> [EMAIL PROTECTED] wrote on 06/22/2006 01:37:13 PM:
>
>> Toby Corkindale wrote:
>>> Hi,
>>> There's a patch attached for Catalyst::Plugin::PageCache.
>>> (It's not final, but more a "request for comments" on it so far. In
>>> particular, some better way
On Thu, 2006-06-22 at 14:01 -0500, [EMAIL PROTECTED] wrote:
> Or have the first hit after the expire set the expire time counter to the
> next interval so the next hit does not even think to rebuild. Then you can
> also rebuild the cache to a temp name and overwrite the current cache when
> it is
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2006-06-22 21:05]:
> Or have the first hit after the expire set the expire time
> counter to the next interval so the next hit does not even
> think to rebuild. Then you can also rebuild the cache to a
> temp name and overwrite the current cache when it is c
[EMAIL PROTECTED] wrote on 06/22/2006 01:37:13 PM:
> Toby Corkindale wrote:
> > Hi,
> > There's a patch attached for Catalyst::Plugin::PageCache.
> > (It's not final, but more a "request for comments" on it so far. In
> > particular, some better way than using flock())
>
> Why not just use
Toby Corkindale wrote:
> Hi,
> There's a patch attached for Catalyst::Plugin::PageCache.
> (It's not final, but more a "request for comments" on it so far. In
> particular, some better way than using flock())
Why not just use pid+tid and a cache key set/get to see if you're the one
doing the bui
Hi,
There's a patch attached for Catalyst::Plugin::PageCache.
(It's not final, but more a "request for comments" on it so far. In
particular, some better way than using flock())
PageCache's objective is to let you cache pages that are "heavy" to create.
However, the potential exists for a page
19 matches
Mail list logo
