The current memcached-1.4.5 version I downloaded appears to always be built with multithreaded support (unless something subtle is happening during configure that I haven't noticed). Would it be OK if I submitted a patch that allows a single-threaded memcached build? Here is the rationale: instead of peppering the code with expensive user- space locking and events (e.g. pthread_mutex_lock, and the producer- consumers), why not just have the alternative to deploy N instances of plain singlethreaded memcached distinct/isolated processes, where N is the number of available CPUs (e.g. each instance on a different port)? Each such memcached process will utilize 1/Nth of the memory that a `memcached -t N' would have otherwise utilized, and there would be no user-space locking (unlike when memcached is launched with `-t 1'), i.e. all locking is performed by the in-kernel network stack when traffic is demuxed onto the N sockets. Sure, this would mean that the clients will have to deal with more memcached instances (albeit virtual), but my impression is that this is already the norm (see the consistent hashing libraries like libketama), and proper hashing (in the client) to choose the target memcached server (ip:port) is already commonplace. The only down-side I may envision is clients utilizing non-uniform hash functions to choose the target memcached server, but that's their problem.
Regards, T
