I think Facebook would be delighted to not have to shoehorn our future
modifications into a "can work in either threaded or non-threaded
mode" framework. There's some stuff we have talked about doing that
would be much more straightforward to implement if we knew we could
always count on being able to spawn threads in the background. (For
example, alternate memory allocators with background defragmentation.)
So +1 from me. The only reason I did the mixed-mode implementation
when I initially added thread support was because of the belief that
lots of people still wanted to run single-threaded, which honestly
didn't make much sense to me at the time -- but it's not my project
and it didn't seem worth forking the code, so I went with it. As time
goes on it makes less and less sense to continue to support.
-Steve
On Feb 7, 2008, at 11:54 AM, Brian Aker wrote:
Hi!
Basically:
1) No one buys single processors machines today.
2) Memcached should be as simple to install as possible.
3) Less code to maintain means less... well work.
4) Single points of execution makes code less buggy and easier to
understand.
So lets pull the non-thread code out of memcached and default to
just the threaded version.
Any objections?
Cheers,
-Brian
--
_______________________________________________________
Brian "Krow" Aker, brian at tangent.org
Seattle, Washington
http://krow.net/ <-- Me
http://tangent.org/ <-- Software
http://exploitseattle.com/ <-- Fun
_______________________________________________________
You can't grep a dead tree.
