On Thu, May 14, 2009 at 04:23:22PM -0700, Chris Darroch wrote: > 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?)
w.r.t. locking, my take for socache was: you either duplicate the code in every provider, or you duplicate the code in every API consumer, so it wasn't obvious what was best. I expected the latter would be both simpler and more flexible, so went for that. There's a general problem that we have mutex code duplicated poorly across the server: 1) config hooks allowing the admin to specify location and maybe lock type, 2) initialization, mostly unified via _set_global_mutex_perms, 3) lock/unlock calls which maybe log errors, and maybe fail correctly which is a bit of a mess. I've wondered before whether some central API could simplify this, such that with little extra module code, you could get a mutex which could be configured via e.g.: Mutex slotmem fcntl:/var/run/slotmem.lck and if not configured, sensible defaults are used. But I'm not sure whether it could be done to really improve the server and avoid being an abstraction-fest code-bloat effort. Regards, Joe
