Christopher Key wrote:
Yann Lavictoire wrote:
<Big snip>
Ok, given your most recent post, I can see what you're doing now. I
also think a mail client somewhere along the way had borken you're
original code slightly, did you mean,
struct {
...
} myvar;
apr_pool_t *p;
This still seems like a bad idea, albeit somewhat less less than before,
and with examples of situations where things break being a little less
obvious. Nevertheless, it does remove some of the freedom the APR had
with the way it implemented things behind the scenes, and means that
there's more to be mindful of whilst coding platform specific
implementations of things.
A couple of examples:
APR may reference members of apr_pool_t, both directly and via contained
pointers:
struct s {
int a;
int b;
int *c;
}
int main(...) {
struct s *s1;
struct s s2;
make(&s1);
memcpy(&s2, s1, sizeof...);
do(&s2);
}
void make(struct s **ptr) {
*ptr = malloc(sizeof(**ptr));
ptr.a = 0;
ptr.b = 0;
if (...) { ptr.c = &(ptr.a); } else {ptr.c = &(ptr.b); }
}
void do(struct s *ptr) {
ptr->a++;
ptr->b++;
*(ptr->cur) *=2;
}
APR may also want to keep track of all pools created and their usage,
maybe for a future memory usage API or similar. Obviously, APR will
only know about the apr_pool_t that it returned a pointer to, and
nothing about the copied version, so can't keep track of how its being
used.
I would say that alignment could still be an issue, although is probably
unlikely to. A platform may require that an apr_pool_t end up on a
specific boundary for some reason (quite independent of its size). APR
can force this when it allocates storage is required, but when the
storage is allocated for myvar, there's no such guarantee.
Admittedly, these are rather contrived examples, but they are still
illustrating extra requirements for APR implementations that aren't
there with purely opaque types and pointers. This increase in
complexity of the how APR can implement things cannot be good, and just
seems likely to lead to problems to me.
Kind regards,
Chris
Good point, thanks for your example.
Since apr_pool_t only contains "direct" pointers, it doesn't apply to it but I admit the sizeof() and memcpy() doesn't
work on opaque structs.
My changes have to be done in the apr_pools implementation I'm afraid ...
Ryan Bloom wrote:
> On Fri, Jun 6, 2008 at 9:18 AM, Yann <[EMAIL PROTECTED]> wrote:
>> Erik Huelsmann wrote:
>>> On 6/6/08, Ryan Bloom <[EMAIL PROTECTED]> wrote:
>>>> I don't think that there is any reason to not have a sizeof()
>>>> function, other than any code that does "play" with the pointers will
>>>> be non-portable code. The reason that I originally went with opaque
>>>> data structures (I did it before giving the code to the ASF), was that
>>>> most of the structures are defined totally differently on each
>>>> platform. By making the structures opaque, it became much harder for
>>>> a developer to write code with APR that worked on some APR platforms,
>>>> but not others. If you play with the pointers, your code is very
>>>> likely to work only on the platforms that you code on.
>>>>
>>>> But, I would like to hear from some of the active developers about this
>>>> as well.
>>> Well, as soon as you provide its size, it's not completely opaque
>>> anymore, now is it :-)
>>>
>> Yes of course, but as soon you provide an accessor it isn't neither ...
>>
>>> I think the entire issue is centered around the fact that Yann doesn't
>>> really want to play by the pool-rules...
>>>
>> I would love to play with the APR pools if they could become subpools of
>> others after their creation.
>>
>> That is, a pool being the whole object (destroyed with its pool), and
>> objects living or dying with their changing owners.
>>
>> Why couldn't that be compatible with the pool rules ?
>
Ryan Bloom wrote:
> If this is what you really want/need, then I would suggest focusing on
> a patch that implements this functionality.
>
> Ryan
>
OK, I can try to do that although I feel some sarcasm in your suggestion, don't
you think it is possible ?
Moreover, my solution looks quite simple and I'm afraid it has already been
discussed in this list, but I give a try ...
If I had to do a patch, I would try to use the apr_pool_cleanup_register()ing / _kill()ing mechanism to bind the pools
each others.
Including the subpools that would just be pools registered in the cleanups list
of their parent/owner.
Do you see another constraint, for a pool to be lately attached to another parent/owner, than the two pools have to use
the same allocator and the to-attach pool *not* to be an ancestor of the attached owner/parent pool (that is, not having
its own cleanup registered in the owner) ?
I'm surely missing something, and I surely need some advices,
regards,
Yann.
