Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of jorton@redhat.com designates
 66.187.237.31 as permitted sender)
Date: Mon, 16 Feb 2009 10:07:47 +0000
From: Joe Orton <jorton@redhat.com>
To: Graham Dumpleton <graham.dumpleton@gmail.com>
Cc: dev@httpd.apache.org
Subject: Re: Problems with EOS optimisation in ap_core_output_filter() and
	file buckets.
Message-ID: <20090216100746.GA5873@redhat.com>
Mail-Followup-To: Graham Dumpleton <graham.dumpleton@gmail.com>,
	dev@httpd.apache.org
References: <88e286470902131525v57cfaab1s58f84c0f76cf264a@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <88e286470902131525v57cfaab1s58f84c0f76cf264a@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor,
 Berkshire, SL4 1TE, United Kingdom.
  Registered in UK and Wales under Company Registration No. 03798903
  Directors: Michael Cunningham (USA), Brendan Lane (Ireland),
 Matt Parson (USA), Charlie Peters (USA)

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