httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davi Arnaut <d...@haxent.com.br>
Subject Re: [PATCH] mod_disk_cache working LFS (filecopy)
Date Mon, 02 Oct 2006 13:36:13 GMT
Niklas Edmundsson wrote:
> On Sun, 1 Oct 2006, Davi Arnaut wrote:
> 
>>>> store_body:
>>>> 	.. if (is_file_bucket(bucket))
>>>> 		copy_file_bucket(bucket, bb);
>>> Probably, but that doesn't allow for creating a thread/process that
>>> does the copying in the background, which is my long term goal.
>>>
>>> Also, simply doing bucket_delete like that means that the file will
>>> never be sent to the client, which is a bad thing IMO ;)
>> Shame on me, but I said "something like".. :)
>>
>> I guess the attached patch does the same (plus mmap, et cetera) and is
>> much simpler. Comments ?
> 
> Simpler, yes. But it only has the benefit of not eating all your 
> memory...

Well, that was the goal. Maybe we could merge this one instead and work
together on the other goals.

> * It leaves the brigade containing the uncached entity, so it will
>    cause the backend to first deliver stuff to be cached and then stuff
>    to the client.

Yeah, that's how mod_disk_cache works. I think it's possible to work
around this limitation without using threads by keeping each cache
instance with it's own brigades and flushing it occasionally with
non-blocking i/o.

Or we could move all disk i/o to a mod_disk_cache exclusive thread pool,
it could be configurable at build time whether or not to use a thread pool.

Comments ?

> * When this evolves to wanting to spawn a thread/process to do the
>    copying you'll need the "is this a file"-thingie anyway (at least I
>    need it, but I might have missed some nifty feature in APR).

You would just need to copy the remaining buckets (granted if there are
no concurrency problems) and send then to a per-process thread pool.

--
Davi Arnaut

Mime
View raw message