httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <>
Subject Re: pool vs. context
Date Wed, 12 Apr 2000 03:37:28 GMT
search the archives for long long long rants.

many of us advocated that we just put the context foo into ap_pool_t and
not change massive amounts of code.  in fact we predicted confused

nice to see that prediction come true :)

what is really confusing me right now as i study the APR code and try to
figure out if the ap_{set,get}_userdata API is even used is that there are
numerous functions which all just wrap ap_{set,get}_userdata:

% rgrep 'ap_[sg]et_[a-z]*data'
./apr_file_io.h:ap_status_t ap_get_filedata(void **data, char *key, ap_file_t *file);
./apr_file_io.h:ap_status_t ap_set_filedata(ap_file_t *file, void *data, char *key,
./apr_general.h:ap_status_t ap_set_userdata(void *data, char *key,
./apr_general.h:ap_status_t ap_get_userdata(void **, char *key, ap_context_t *cont);
./apr_lock.h:ap_status_t ap_get_lockdata(ap_lock_t *lock, char *key, void *data);
./apr_lock.h:ap_status_t ap_set_lockdata(ap_lock_t *lock, void *data, char *key,
./apr_network_io.h:ap_status_t ap_get_socketdata(void **data, char *key, ap_socket_t *sock);
./apr_network_io.h:ap_status_t ap_set_socketdata(ap_socket_t *sock, void *data, char *key,
./apr_network_io.h:ap_status_t ap_get_polldata(ap_pollfd_t *pollfd, char *key, void *data);
./apr_network_io.h:ap_status_t ap_set_polldata(ap_pollfd_t *pollfd, void *data, char *key,
./apr_thread_proc.h:ap_status_t ap_get_threaddata(void **data, char *key, ap_thread_t *thread);
./apr_thread_proc.h:ap_status_t ap_set_threaddata(void *data, char *key,
./apr_thread_proc.h:ap_status_t ap_get_threadkeydata(void **data, char *key, ap_threadkey_t
./apr_thread_proc.h:ap_status_t ap_set_threadkeydata(void *data, char *key,
./apr_thread_proc.h:ap_status_t ap_get_procdata(char *key, void *data, ap_proc_t *proc);
./apr_thread_proc.h:ap_status_t ap_set_procdata(void *data, char *key,

i thought the purpose of having the userdata stuff in the context was that
it could be accessed from anywhere the context could be accessed.

i don't understand why we need all these extra functions.  at worst we
should have an ap_get_filectx, ap_get_userctx, ... to fetch back the
context pointer.


On Tue, 11 Apr 2000, Mike Abbott wrote:

> The use of pools and contexts in 2.0 confuses me.  There are
> distinct types (ap_pool_t, ap_context_t) and
> constructors/destructors (ap_make_sub_pool()/ap_destroy_pool(),
> ap_create_context()/ap_destroy_context()) but many variables are
> declared as ap_context_t and named "pool" (the first member of
> request_rec) or "p" (the "p" in all the ap_pXXX() function names
> and objects like "pglobal").  I understand that the "pool"
> concept is inherited from 1.3 and "contexts" are new in 2.0 but
> the split seems incomplete.  Seems to me either all stale
> references to pools should be changed to contexts (e.g.,
> ap_pstrdup() becomes ap_cstrdup()), or pools should become, say,
> "arenas" and contexts should switch back to being pools (so that
> ap_pstrdup(r->pool, ...) makes sense but ap_make_sub_pool()
> becomes ap_make_sub_arena()), or I need something explained to
> me.
> I think that, at a minimum, ap_clear_pool() should be renamed to
> ap_clear_context() since MPMs operate on contexts not pools:
> src/modules/mpm/dexter/dexter.c:863:    ap_create_context(&ptrans, tpool);
> src/modules/mpm/dexter/dexter.c:979:        ap_clear_pool(ptrans);
> --
> Michael J. Abbott

View raw message