On Mon, Apr 27, 2020 at 6:17 PM Joe Orton wrote:
>
> On Mon, Apr 27, 2020 at 04:27:56PM +0200, Yann Ylavic wrote:
> > On Mon, Apr 27, 2020 at 4:11 PM Joe Orton wrote:
> > >
> > > +1 from me for using the term "opaque buckets" as a synonym for
> > > "e->length == (apr_size_t)-1" aka "buckets with
On Mon, Apr 27, 2020 at 04:27:56PM +0200, Yann Ylavic wrote:
> On Mon, Apr 27, 2020 at 4:11 PM Joe Orton wrote:
> >
> > +1 from me for using the term "opaque buckets" as a synonym for
> > "e->length == (apr_size_t)-1" aka "buckets with indeterminate length".
>
> OK thanks, just committed "somethi
On Mon, Apr 27, 2020 at 4:11 PM Joe Orton wrote:
>
> +1 from me for using the term "opaque buckets" as a synonym for
> "e->length == (apr_size_t)-1" aka "buckets with indeterminate length".
OK thanks, just committed "something" in r1877077 because I keep
messing up with my attachments today.
Let'
On Mon, Apr 27, 2020 at 03:57:37PM +0200, Yann Ylavic wrote:
> On Mon, Apr 27, 2020 at 3:43 PM Yann Ylavic wrote:
> >
> > On Mon, Apr 27, 2020 at 2:09 PM Yann Ylavic wrote:
> > >
> > > https://github.com/apache/httpd/pull/117
> >
> > I closed it, how about the second patch there though?
> >
> > h
On Mon, Apr 27, 2020 at 3:57 PM Yann Ylavic wrote:
>
> On Mon, Apr 27, 2020 at 3:43 PM Yann Ylavic wrote:
> >
> > On Mon, Apr 27, 2020 at 2:09 PM Yann Ylavic wrote:
> > >
> > > https://github.com/apache/httpd/pull/117
> >
> > I closed it, how about the second patch there though?
> >
> > https://
On Mon, Apr 27, 2020 at 3:43 PM Yann Ylavic wrote:
>
> On Mon, Apr 27, 2020 at 2:09 PM Yann Ylavic wrote:
> >
> > https://github.com/apache/httpd/pull/117
>
> I closed it, how about the second patch there though?
>
> https://github.com/apache/httpd/pull/117/commits/cdf4c4a3c61340f061267cc70c456d9
On Mon, Apr 27, 2020 at 2:09 PM Yann Ylavic wrote:
>
> https://github.com/apache/httpd/pull/117
I closed it, how about the second patch there though?
https://github.com/apache/httpd/pull/117/commits/cdf4c4a3c61340f061267cc70c456d9469e9faac
On Mon, Apr 27, 2020 at 3:04 PM Joe Orton wrote:
>
> On Mon, Apr 27, 2020 at 02:29:55PM +0200, Yann Ylavic wrote:
> > The call chain is:
> > apr_bucket_setaside(bucket, newpool)
> > => file_bucket_setaside(bucket, newpool)
> > => apr_file_setaside(&newfd, bucket->data->fd, newpool)
> >
On Mon, Apr 27, 2020 at 02:29:55PM +0200, Yann Ylavic wrote:
> The call chain is:
> apr_bucket_setaside(bucket, newpool)
> => file_bucket_setaside(bucket, newpool)
> => apr_file_setaside(&newfd, bucket->data->fd, newpool)
> => copy bucket->data->fd to newfd, move cleanup to newpool
On 4/27/20 2:29 PM, Yann Ylavic wrote:
> On Mon, Apr 27, 2020 at 11:11 AM Joe Orton wrote:
>>
>> On Sun, Apr 26, 2020 at 05:26:02PM +0200, Yann Ylavic wrote:
>>> For FILE buckets, the behaviour of apr_bucket_setaside() is to take
>>> *full* ownership of the underlying apr_file, that is: allocat
On Mon, Apr 27, 2020 at 11:11 AM Joe Orton wrote:
>
> On Sun, Apr 26, 2020 at 05:26:02PM +0200, Yann Ylavic wrote:
> > For FILE buckets, the behaviour of apr_bucket_setaside() is to take
> > *full* ownership of the underlying apr_file, that is: allocate/move
> > the file/cleanup to the new pool AN
On Mon, Apr 27, 2020 at 9:24 AM Ruediger Pluem wrote:
>
> On 4/26/20 5:26 PM, Yann Ylavic wrote:
>
> > So, how about we do that?
> > Would look like the attached patch (which also removes the misleading
>
> Did I miss the attachment? :-)
Argh :/
> Or even better, can we have this as a PR against
On Sun, Apr 26, 2020 at 05:26:02PM +0200, Yann Ylavic wrote:
> For FILE buckets, the behaviour of apr_bucket_setaside() is to take
> *full* ownership of the underlying apr_file, that is: allocate/move
> the file/cleanup to the new pool AND set the old file's fd to -1 (see
> apr_file_setaside, [1]).
> Am 26.04.2020 um 17:26 schrieb Yann Ylavic :
>
> After a look at our codebase, this would work as is, all of the FILE
> buckets we pass through output filters are from r->pool, so the
> lifetime is within the EOR scope (I'm not totally sure about the http2
> beam case, Stefan?).
Lacking a nam
On 4/26/20 5:26 PM, Yann Ylavic wrote:
> So, how about we do that?
> Would look like the attached patch (which also removes the misleading
Did I miss the attachment? :-)
Or even better, can we have this as a PR against trunk on github? This ensure
that it has run already through all the Travi
For FILE buckets, the behaviour of apr_bucket_setaside() is to take
*full* ownership of the underlying apr_file, that is: allocate/move
the file/cleanup to the new pool AND set the old file's fd to -1 (see
apr_file_setaside, [1]).
This can be problematic in an output filters chain whenever a FILE
16 matches
Mail list logo
