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
