GNOME Bugzilla – Bug 552994
GTimer doesn't handle suspend/resume correctly when called after g_thread_init
Last modified: 2012-01-10 18:19:15 UTC
Please describe the problem: If I start a GTimer, then suspend and resume my computer for an hour, the GTimer will report that an hour has passed. However, if I first call g_thread_init(), then start a GTimer and suspend/resume, the timer will report that no time has passed at all Steps to reproduce: 1. Compile and run the attached test case. 2. Suspend. 3. Resume. 4. Comment out the g_thread_init line in the test case. Recompile, run. 5. Suspend 6. Resume. Actual results: First time: you'll see 1,2,3,4 etc. with no break when you suspended. Without threading: you'll see 1,2,3,4,5, 3605,3606, if you suspend for an hour. Expected results: You should always see 1,2,3,4,5, 3605,3606, if you suspend for an hour. Does this happen every time? Yes Other information:
Created attachment 119031 [details] Test case Can be compiled with something like: gcc -Wall -pthread -lgthread-2.0 -lrt -lglib-2.0 -I/usr/include/glib-2.0 -I/usr/include -I/usr/lib/glib-2.0/include -L/usr/lib test.c /usr/lib/libglib-2.0.a -o test
The GTimer documentation doesn't seem to be very clear whether it's intended to be wall clock or program-execution-relative time. My guess is it is intended to be the latter, in which case this behavior is a just bug when you don't call g_thread_init (and generally you always should). Needs more investigation though.
"GTimer records a start time, and counts microseconds elapsed since that time." Clear enough. If time stops when the computer is turned off, the documentation should say so. gnome-typing-monitor relies on the expected behaviour I suggest. Also, if you just suspend the program with Ctrl+Z, GTimer does not stop counting (even with g_thread_init() called). So the behaviour when the computer suspends is inconsistent.
There were no activity on this bug for months. But it seems that people are waiting for some kind of a solution. This bug was started because of bug #430797 saying that typing break cannot see suspend time. And as I can see, many clones of this bug emerges constantly on different bugzillas, as Fedora, Ubuntu, etc. They are marked as duplicates and nothing is happening. 4 bugs in Gnome bugzilla, eg. http://bugzilla.gnome.org/show_bug.cgi?id=430797 At least 2 bugs in Ubuntu, eg. https://bugs.launchpad.net/ubuntu/+bug/318403 At least 2 in Fedora, eg. https://bugzilla.redhat.com/show_bug.cgi?id=485588 I can see bugs from begining of 2007 (two years ago!) saying that typing break behaviour is annoying. One should remember that only a small fraction of users can and actually do report bugs.
If there is a problem with the typing break monitor, file a bug against the typing breaking monitor! Trying to put a system-level semantic like "counts time only when the computer is not suspended" into a simple low-level class like GTimer makes no sense. The typing break just needs to catch the appropriate notification on resume and reset. It's obviously a little weird if GTimer behaves differently depending on whether or not threading is enabled, but that's not the typing break's concern. GTimer is really meant for thing like "if I run this loop 10,000 times, how long does it take".
(In reply to comment #0) > if I first call g_thread_init() Since 2.31.0, GTimer is always monotonic, whether you call g_thread_init() or not.