GNOME Bugzilla – Bug 660741
g_cond_timedwait is a disaster
Last modified: 2011-10-14 14:22:37 UTC
This is an API that takes an absolute value in wallclock time when every single user of it wants to give a relative value in monotonic time. On the other hand, due to the possibility of spurious wakeups (and the restarts that should ideally accompany them), an absolute time API is potentially better. Either way, we should use gint64-based time instead of GTimeVal and it should be based on monotonic time.
didn't you just add a guint64-taking variant ?
Ya. I'm still not happy, since it's gint64 in wallclock time. It's a bit complicated -- the clock associated with a pthread condition variable has to be selected at the time that the condition variable is initialised. That's actually not so difficult now that we always explicitly call pthread_cond_init() internally. The problem is that we still have this existing API that takes wallclock time. I was considering an evil solution: GCond made with g_cond_new() are wallclock-based and GCond made with g_cond_init() and static storage are monotonic. That means we have no breaks in API as far as existing programs are concerned. The other alternative is to make all GCond monotonic-based and to try to shuffle around the incoming GTimeVal from wallclock to monotonic time... The other thing is that most people probably want a relative timeout instead of an absolute one. Benjamin and I were arguing over how much I should give into that...
http://pubs.opengroup.org/onlinepubs/000095399/functions/pthread_cond_wait.html has a rationale for why posix uses absolute times
Okay. I nuked g_cond_timedwait() and added g_cond_wait_until() with the same signature but different semantics (monotonic time instead of wallclock time). The rename is due to the fact that timedwait was a lame name and I want to give a chance to anyone who adopted the API already to be made aware of the fact that the argument passed to it has changed its meaning. I also deprecated the wallclock-based API. It's racy and nobody should ever use it. We still have GTimeVal* wallclock APIs on GAsyncQueue that are calling the deprecated API. We should probably deprecate those for favour of monotonic or relative-time ones (there is no need for absolute time in this case since the looping is done internally).