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?
Cheers
Jean-Frederic
