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
