apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann ...@bee-ware.net>
Subject Re: Opaque structures in general (was Re: Opaque apr_pool_t structure)
Date Fri, 06 Jun 2008 15:10:44 GMT
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 <yl@bee-ware.net> wrote:
 >> Erik Huelsmann wrote:
 >>> On 6/6/08, Ryan Bloom <rbloom@gmail.com> 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.

Mime
View raw message