> Hello. > My apologies for not providing a patch for this and deadlock issue. > (i think it can be solved using memory based posix semaphore placed in > shared mem. FreeBSD supports posix sem since 7.2) > If i manage my time (maybe this summer) ill do my best to help > improve uwsgi as i think it is cool project. (besides i am a primary a > pythonist.) > > I just investigated on problem that was bothering me from time to > time: how to property measure time. > Here is a good link explaning a problem and giving solution > > http://blog.habets.pp.se/2010/09/gettimeofday-should-never-be-used-to-measure-time > > I think uwsgi should use CLOCK_MONOTONIC (better > CLOCK_MONOTONIC_RAW on linux) and clock_gettime. Yes it is a rare > problem but just a few month ago i found > that our productions servers wasnt running ntp and there was 1-5 min > deviation in server time. So i said to admins and it was a bit scary > to look how admin synced time in production. I did not checked but i > think if i skew system clock backward 10 sec with harakiri set to 10 > that will kill all active workers. > (in set_harakiri : uwsgi.workers[uwsgi.mywid].harakiri = time(NULL) + > sec;) > > > Best regards. > >
This is defintely an issue all of the sysadmin should know, but programmers tend to not care (hoping in good sysadmin behaviour). Honestly i think it would be real hard to take in account clock skew, but i admit not being an expert about that. (from what you have wrote, it looks like substituting time() with clock_gettime() should be enough, but i do not think world is such a beatiful place ;) Your analisys is right, and i have faced this problem lot of times (being an ISP, when we make mess with clock lot of customers complaints...). This problem happens even when you use chroot() with a different localtime (Cal of Simplicity Media experienced that some month ago, and it was the first time i realized how time()/gettimeofday() are weak) Can you open a ticket about that ? Maybe we could add that as a feature for 1.2 -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
