httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Darroch <chr...@pearsoncmg.com>
Subject Re: slotmen API thoughts
Date Sat, 03 Jan 2009 00:48:06 GMT
Jim Jagielski wrote:

>>   - create()   - takes num_items and item_size
>>                - to be called during initial config pass, providers
>>                  should not initialize or create mutexes here, etc.
> 
> "should not"??

   That comes from writing mod_shmap which lets you load a bunch of
socache providers in a kind of test harness; see my notes to myself
in shmap_check_config() and shmap_post_config() in
http://people.apache.org/~chrisd/projects/shared_map/mod_shmap.c.

   The socache providers' create() functions conveniently all just
alloc a struct or two to hold the config parameters they've been passed,
and sometimes throw config-time error if those don't make sense.  But
nothing important actually here; no shared memory allocations, etc.

   Thus it's quite convenient to call these create() functions in the
check_config phase because errors caused by bad config directives still
get sent to the command line (unlike the post_config phase).  But
mod_shmap only makes these calls the first time check_config runs --
after that, it means it's in a running server and so the create()
functions are skipped.

   Conversely, the socache providers' init() functions all really
do "stuff" like allocating shared memory.  So mod_shmap calls those
in post_config, and only when it's not the first time post_config is
called.  That way server processes which are just going to signal
a running server to restart or shutdown don't bother allocating
shared memory, opening files or sockets, etc.

   It's also in that second-time-or-later post_config phase that
mutexes are created in mod_shmap, if the socache provider is
marked NOTMPSAFE.

   In all cases mod_shmap passes the pconf pool to the socache
providers (and the mutexes) so everything they do will be cleaned up
upon a restart.


> I agree that abstracting out get/set (or retrieve/store) allows
> for more generic usages... also allows for the provider itself
> to determine if mutexes are needed or not... Maybe I'll have
> some time over the weekend to hash this out.

> After researching, typedef's abstraction alleviates this
> issue. So I'll start working on getter/setter functions for
> slotmem and removing user-land locks. But I won't commit
> anything until 2.3.1 is released...

   Cool -- let me know if I can assist.

   FWIW, with socache (IIRC) locks are advisory -- the providers don't
implement them, but just indicate with a flag that they're necessary
for atomic data operations in an MP context.

   I kind of like that, especially for slotmem, because it means users
can ignore the advisory if they know an item is written exclusively
by one writer at all times, and they don't care about readers seeing
partially-written data.  (E.g., the scoreboard works like that, IIRC.)

   This does assume, of course, that no provider can really "blow up"
if the user decides to forgo locking -- the worst-case is just some
mangled data.  I don't know if that's true with the socache providers
or not, actually.  It may be that you really have to heed that
NOTMPSAFE flag unless you're certain of the provider's internals.  Hmm.

Chris.

-- 
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B


Mime
View raw message