httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hyde <bh...@pobox.com>
Subject Re: Context types in apr
Date Fri, 30 Apr 1999 01:47:16 GMT

This is good, but I don't think it's just exactly 
right.

Every operation needs to have access to a pool.
Every operation needs to have access to the thread.

Both threads and pools are used to encapsulate some
activity, so they look similar.  But pools should
be allowed to out number threads.

For example I often write code like this:

  foo *create_foo(ap_pool *p, ...)
  {
     ap_pool *foo_pool = create_sub_pool(p);
     foo *new_foo = (foo *)ap_alloc(p, sizeof(foo));
     foo->pool = foo_pool;
     ap_register_cleanup(foo, foo_cleaner);
     foo-> ...
  }

  void *destroy_foo(foo *f)
  {
    ap_destroy_pool(f);
    return NULL;
  }

Then foo can live for a period shorter than it's
parent pool and when it finishes I can clean up
the memory the activites around foo needed.

I'd lean toward just being sure that every datum
has a pool pointer in it and that ever pool has
a pointer to the thread.  Then you only need to
pass a pool to the creation routines, and a
since the other operations on that datum can
use it's pool for their temporary needs.

  gum *gum_create(ap_pool *p, flavor x)
  {
    gum *g = (gum *)ap_alloc(p, sizeof(gum));
    g->pool = p;
    g->flavor = x;
  }

  void *gum_chew(gum *g)
  {
    body *b = (body *)(g->pool->thread->parent->state);
    mouth *m =  b->mouth;
    lock *lk = m->lock;
    lock(lk);
    mouth_chew(m, g);
    unlock(lk);
  }

In this example the thread might implement the afternoon
while the pool passed to gum_create might only span
the afternoon snack.

  - ben

Mime
View raw message