httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-frederic Clere <>
Subject Re: Additing a storage for the shared information of the worker in mod_proxy
Date Thu, 13 Jul 2006 15:55:01 GMT
Brian Akins wrote:

> Jim Jagielski wrote:
>> If this is data that needs to be accessed from "non-proxy" modules
>> then yes, I agree.
> A basic API could look like.  By worker, I am thinking about the mpm 
> sense, not the proxy sense.  I guess "slot" may be a better term:
> /*used for ap_scoreboard_do. mem is the memory associated with a 
> worker, data is what is passed to ap_scoreboard_do. pool is pool used 
> to create scoreboard*/
> typedef apr_status_t ap_scoreboard_callback_fn_t(void* mem, void 
> *data, apr_pool_t *pool);
> /*call the callback on all worker slots*/
> AP_DECLARE(apr_status_t)ap_scoreboard_do(ap_scoreboard_t *s, 
> ap_scoreboard_callback_fn_t *func, void *data, apr_pool_t *pool);
> /*create a new scoreboard with each item size is item_size.  name is a 
> key used for debuggin and in mod_status output. This would create 
> shared memory, basically*/
> AP_DECLARE(apr_status_t) ap_scoreboard_create(ap_scoreboard_t **new, 
> const char *name, apr_size_t item_size, apr_pool_t *pool);
> /*get the memory associated with this worker slot. use c->id or c->sbh 
> to get offset into shared memory*/
> AP_DECLARE(apr_status_t) ap_scoreboard_mem(ap_scoreboard_t *s, 
> conn_rec *c, void**mem);
> Thoughts.  Somthing very similar to this is used by several very busy 
> web sites...
With such an interface you assume only one process will access to one 
slot... That is what the scoreboard allows.
Allowing updates from different proccesses on the same slot.
Should we have an ap_slot_read_look() and an ap_slot_unlock() for that?



View raw message