Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: error (idunn.apache.osuosl.org: domain acc.umu.se from
 130.239.18.156 cause and error)
Date: Wed, 27 Sep 2006 15:08:02 +0200 (MEST)
From: Niklas Edmundsson <nikke@acc.umu.se>
To: dev@httpd.apache.org
Subject: Re: [PATCH] mod_disk_cache working LFS (filecopy)
In-Reply-To: <49969.196.8.104.37.1159360079.squirrel@www.sharp.fm>
Message-ID: <Pine.GSO.4.64.0609271506270.22063@kleopatra.acc.umu.se>
References: <Pine.GSO.4.64.0609261030000.14519@kleopatra.acc.umu.se>   
 <4519512A.6030402@sharp.fm>
    <Pine.GSO.4.64.0609271053180.22063@kleopatra.acc.umu.se>
 <49969.196.8.104.37.1159360079.squirrel@www.sharp.fm>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Wed, 27 Sep 2006, Graham Leggett wrote:

> On Wed, September 27, 2006 11:07 am, Niklas Edmundsson wrote:
>
>> In practice this isn't enough when dealing with large files, so in our
>> production code (the hideously large jumbopatch) this is fixed by
>> read-while-caching and spawning a thread to do the caching in the
>> background while delivering the response (by read-while-caching) to
>> the client that initiated the caching.
>
> A thread makes sense for platforms that support threads, but we would need
> some kind of functional behaviour for platforms that don't have threads.
> Would the option of spawning a process to copy the file also work, leaving
> the original process to read-while-cache the response for the benefit of
> the client?

We have code for it, it's just untested since we're using the worker 
mpm. We'll deal with that when I get to those patches.

/Nikke
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se      |     nikke@acc.umu.se
---------------------------------------------------------------------------
  Dyslexia rules KO.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=