On Tue, 21 Sep 2010 03:18:30 -0300 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> said:
> Hello all, > > As we all know ecore uses gettimeofday() to retrieve the time and > schedule timeouts. Our own code in ecore and even elementary just use > relative times, and we often have to resort to hacks to detect when > timezone changes or user sets time. > > In order to solve this problem there is an API called clock_gettime() > that may receive a parameter CLOCK_MONOTONIC. The origin is not > guaranteed (often it is implemented as 0 = machine boot), but it does > guarantee time does not go back. > > Raster says that ecore_time_get() and ecore_loop_time_get() are not > supposed to return the unix epoch, although the implementation and > thus the documentation said so... that lead people to use it as such > (a quick grep in svn shows people often save this value to know > timestamps... which is quite wrong). > > So we can fix it in 3 ways: > > 1. apply the attached patch that turns > ecore_time_get()/ecore_loop_time_get() into monotonic, change > occurrences of ecore_time_get()/ecore_loop_time_get() to be > ecore_unix_time_get() (actually in some places they must be changed to > something else, like gmtime or localtime) for now in the cases where they need changing - unixtime is fine. it's "as good as it is now". > 2. create a new patch that introduces ecore_monotonic_time_get() > and uses that from inside ecore_main.c that may or may not be as good. i'd go for #1. yes - i know. a little upsetting, but the calls were not REALLY intended as long-term time getters, just short-term - ie at runtime to compare points in time while an app runs to maintain a nice timeline. > 3. change the attached patch to at start do a gettimeofday() and > register the time difference, then always consider that difference. it > would be monotonic but with Epoch as reference... this may be > extremely buggy if the system has a bad battery and clock is just set > by ntp after your efl program is running. i'd do this in combo with ##1 - it makes old code "break less". but then again - it makes it hard for 2 processes to compare the same timepoint. then again the time get can be defined as "relative to a point in time that will monotonically increase by 1 second per second the process runs, but the 0 point may be any point in time, that is shared between processes or be unique to one process, so the timepoint should be used within 1 process only and only during runtime - not be stored". now have unixtime for doing other things - like sharing timepoints from a known fixed 0 point - that can be used. > 1 is more correct, but maybe too close to 1.0 release to get it, so > although I did the patch I may introduce the way I said in 2... > > comments? suggestions? > > PS: later on I'll provide a patch to ask for a system timer resolution > and probably change poller to behave better wrt wakeups. that's the idea of poller - it's meant to be utterly fuzzy in terms of wakeups - do whatever interrupts a process less and makes for better power management. > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
