httpd-dev mailing list archives

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

>>  At any rate, moving responsibility for locking up to the
>> caller level, as the socache API does, I think makes a lot of
>> sense.  It means that a caller running in a single-process,
>> single-threaded context can simply choose not to add the overhead
>> of a global lock.  Other callers can make their own decisions
>> about what kind of locking they need.

> In general, I think that a provider should know if it is thread-safe
> or not and simply "work" without the user needing to know or worry.
> I think if the provider knows that threads are available AND the MPM
> is threaded, it should by default mutex as required instead of having
> users all need to recreate that externally. If the user says "I don't
> care what MPM I have, don't worry about locking", then I am +1 on a
> flag of some time telling the provider to bypass that.
> 
> Even so, then, I think that we should expose lock/unlock if we make
> this a user-land "you decide if you want to do it or not"... I don't
> think it makes sense having the user/caller have to worry about
> re-inventing the wheel as far as mutexes are concerned just to
> use a provider... A provider should provide the full set of functions
> the end-user should need in order to use it. (imo)

   I saw at least one +1 on this, which is OK by me -- that is,
implementing locks in the providers but then offering a
"use/don't use" flag.

   However, note that any choices we make here also, I believe,
impacts the socache API, which has identical issues around data
consistency in multi-process/multi-thread contexts.  Personally
I'd love to see these two APIs be as congruent as possible
since they both do very similar things.  (Joe, any comments?)

Chris.

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


Mime
View raw message