On Tue, Oct 31, 2006 at 01:49:10PM +0200, Graham Leggett wrote: > On Tue, October 31, 2006 12:59 pm, Joe Orton wrote: > > > I very much sympathise with this argument. But it does mean that the > > storage provider cannot break any of the assumptions mentioned in the > > other thread: it enforces the synchronous store-to-disk and > > write-to-client model. > > > > I think it's a reasonable desire to ship a non-default storage provider > > which implements the "stop and write entire response to disk before > > sending anything to the client" model. But #1 prevents that; such > > tricks could only be done somehow at mod_cache level, or only by > > entirely replacing the cache. > > Are you referring to the existing attempt at achieving "stop and write > entire reponse to disk _while_ independently sending to the client"? > > All the large_disk_cache needs from cache to achieve this is access to > request_rec, which it does in both #1 and #2. > > >From there it's a simple kevent or notifier equivalent to determine > whether the socket buffer is free. Ideally, this should be abstracted into > a convenience function in the core, somelike like ap_write_will_block().
Being able to determine writability from the output filter chain means redesigning the output filtering interface, there is nothing simple about it at all. The point of this thread is to gain consensus on how to make the cache interact properly with the current output filtering API. joe
