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
