httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <>
Subject Re: Problems with EOS optimisation in ap_core_output_filter() and file buckets.
Date Mon, 16 Feb 2009 10:07:47 GMT
On Sat, Feb 14, 2009 at 10:25:08AM +1100, Graham Dumpleton wrote:
> What the end result of the code is, is that if you have a file bucket
> getting this far where length of file is less than 8000 and an EOS
> follows it, then the actual file bucket is held over rather than data
> being read and buffered. This is as commented is to avoid doing an
> mmap+memcpy. What it means though is that the file descriptor within
> the file bucket must be maintained and cannot be closed as soon as
> ap_pass_brigade() has been called.

The call to:

            ap_save_brigade(f, &ctx->b, &b, ctx->deferred_write_pool);

in that code path should result in the FILE bucket and the contained fd 
being dup()ed.  (Though if that is failing, you wouldn't know because of 
the lack of error checking)

You say:

> For me this is an issue as the file descriptor has been supplied from
> a special object returned by a higher level application and it would
> be hard to maintain the file as open beyond the life of the request,
> up till end of keep alive or a subsequent request over same
> connection. Doing a dup on the file decriptor is also not necessarily
> an option.

can you explain why a dup shouldn't work?

Regards, Joe

View raw message