You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Cliff Woolley <jw...@virginia.edu> on 2002/06/30 02:03:58 UTC
Re: [PATCH] apr_file_setaside
On Sat, 29 Jun 2002, Brian Pane wrote:
> This patch adds an apr_file_setaside() function that moves
> an apr_file_t from one pool to another without doing any
> dup(2) or mmap(2) operations.
Why not keep the dup() and add in a "transfer ownership" feature like the
mmap dup uses? After all, the whole reason we added an apr_mmap_dup() was
to allow the apr_mmap_t to be moved from one pool to another. It would
be mildly annoying to have the mmap and file code diverge again...
--cliff
Re: [PATCH] apr_file_setaside
Posted by Cliff Woolley <jw...@virginia.edu>.
On Sat, 29 Jun 2002, Brian Pane wrote:
> #define apr_mmap_setaside(new, old, pool) apr_mmap_dup(new, old, pool, 1);
> /* the '1' at the end is the "transfer ownership" flag
+1, sounds good.
--Cliff
Re: [PATCH] apr_file_setaside
Posted by Brian Pane <bp...@pacbell.net>.
Cliff Woolley wrote:
>On Sat, 29 Jun 2002, Brian Pane wrote:
>
>
>
>>Which dup() do you mean: the dup(2) or the naming convention of
>>using "_dup*()" for this family of apr_file_t functions?
>>
>>
>
>Sorry, I should have been more precise. apr_file_dup() was what I was
>referring to.
>
>On second thought though, I suppose I wouldn't object to
>apr_file_setaside() if we changed apr_mmap_dup() to be apr_mmap_setaside()
>as well... would that make sense? I'm just looking for consistency here,
>not objecting to the concept.
>
I agree: using apr_mmap_setaside() for consistency would make
sense. We probably need to keep apr_mmap_dup() for backward
compatibility, but we could do this:
#define apr_mmap_setaside(new, old, pool) apr_mmap_dup(new, old, pool, 1);
/* the '1' at the end is the "transfer ownership" flag
--Brian
Re: [PATCH] apr_file_setaside
Posted by Cliff Woolley <jw...@virginia.edu>.
On Sat, 29 Jun 2002, Brian Pane wrote:
> Which dup() do you mean: the dup(2) or the naming convention of
> using "_dup*()" for this family of apr_file_t functions?
Sorry, I should have been more precise. apr_file_dup() was what I was
referring to.
On second thought though, I suppose I wouldn't object to
apr_file_setaside() if we changed apr_mmap_dup() to be apr_mmap_setaside()
as well... would that make sense? I'm just looking for consistency here,
not objecting to the concept.
--Cliff
Re: [PATCH] apr_file_setaside
Posted by Brian Pane <bp...@pacbell.net>.
Cliff Woolley wrote:
>On Sat, 29 Jun 2002, Brian Pane wrote:
>
>
>
>>This patch adds an apr_file_setaside() function that moves
>>an apr_file_t from one pool to another without doing any
>>dup(2) or mmap(2) operations.
>>
>>
>
>Why not keep the dup() and add in a "transfer ownership" feature like the
>mmap dup uses?
>
Which dup() do you mean: the dup(2) or the naming convention of
using "_dup*()" for this family of apr_file_t functions?
--Brian