Use specialized clock thread

[GoogleCodeExporter]

We should use a specialized thread for driving the internal clock in
memcached instead of using timer-events from libevent. The problem with
timed events from libevent is that it will try to determine the current
time before each call to poll/select/whatever so that it can provide a
correct timeout value. The intent of the clock events was to avoid calling
time() (with friends) all the time, and instead just drive an internal clock.

Original issue reported on code.google.com by trond.no...@gmail.com on 4 Jun 2009 at 12:56

[GoogleCodeExporter]

See: http://github.com/trondn/memcached/tree/rfe_58

Original comment by trond.no...@gmail.com on 4 Jun 2009 at 1:01

[GoogleCodeExporter]

I commented on a line in your change, but I'll repeat it here just in case 
you're not
looking there.

Shouldn't it shut down the entire process when the clock thread dies?  That 
seems
like a really bad state to be in.

Original comment by dsalli...@gmail.com on 4 Jun 2009 at 3:54

[GoogleCodeExporter]

I guess we could do that. I do however have a problem seeing why clock_gettick 
would fail (looking for the 
documented return codes it shouldn't happen ;) I'll update the patch

Original comment by trond.no...@gmail.com on 4 Jun 2009 at 4:07

[GoogleCodeExporter]

Crashing when things shouldn't happen is acceptable.  :)

I've had long-living processes that used this model to keep up with time and 
the time
thread crashed and went away on its own.  Really bad things happened.  :(

Original comment by dsalli...@gmail.com on 4 Jun 2009 at 6:31

[GoogleCodeExporter]

Nah.. the timers is only used by the thread accepting new clients so it's not a 
big problem...

Original comment by trond.no...@gmail.com on 20 Aug 2009 at 12:48

• Changed state: WontFix