httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Darroch <>
Subject Re: slotmem API notes
Date Thu, 14 May 2009 23:41:40 GMT
Jim Jagielski wrote:

> On May 14, 2009, at 3:36 AM, jean-frederic clere wrote:

> Yeah... when a do is done, we want to ensure that
> none of the slots change since we are touching all slots.
> In general, we assume that with get and put, only one thread is
> touch any particular slot at one time.

   What about multiple processes performing a put() on the same
slot?  It sounds like the current use case tends to be strictly
intra-process, but the API doesn't require that, I believe.

   This is why I'd either pull all the locking out and let
the user decide (none, intra-process [thread mutexes] only,
inter-process [global mutexes], or some custom thing).  The
provider just doesn't know enough to be certain and we end up
doing expensive global locking, or having to provide a Swiss
army knife set of locking options and them implementing them
all in each provider (slotmem and socache).  But that's just
my two cents.

>>>  The init() method then does all the work of actually setting
>>> up the provider's data storage.  The typical use case would
>>> be to call this from the *second* or subsequent invocations of
>>> the post_config hook.  This is how the mod_socache_shmcb provider
>>> functions and like mod_sharedmem is allocates shared memory segments.
> I'm still not clear on the advantages of splitting...

   The primary reason is that you can call create() in a check_config
or post_config hook and report back to the administrator if there
are problems with the arguments passed to the provider.  However,
at this early stage there's no need to be allocating big slabs of
memory -- you just want a sanity check, and a handle allocated.

   Then init() does the actual work in the second post_config
phase, when the server is really getting started (and logs are
up and running, so errors don't go the console anymore, so there's
no nice way to report configuration errors).

>> Well if we want to use it for the scoreboard mem() prevents memcpy().
> I also thought that removing _mem made sense...

   OK, I can see the utility of mem(), but callers should be
warned they might get an APR_ENOTIMPL, I think.

>> we have:
>> grab/return
>> put/get
>> you want:
>> put/set/get/reset.
>> I do see a big difference, except I prefer the first one.
> Yeah... I don't see the advantage for set/reset when we have get/put
> since the end-user can do a set/reset via what they 'put'
> Also, reset is 'release' now... we just need to "null-out" the
> data (if really required...)

   I could easily live without set(); it was just an idea to save
a get()/put() cycle for certain use cases.  Probably better to
drop the idea.

   It does seem to me that instead of adding another pair of
methods (grab() and return()) having just a single reset() or
release() method would be tidier.  For providers which need to track
per-slot usage, it's a way to say "this index now unused".  Any
other action on the slot (get(), mem(), etc.) is effectively a
"this index now used" message.  The three methods then also parallel
the store()/ retrieve()/remove() calls of socache.

   My two cents, anyway.  Thanks for listening!


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

View raw message