After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 660741 - g_cond_timedwait is a disaster
g_cond_timedwait is a disaster
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gthread
unspecified
Other All
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks: 660747
 
 
Reported: 2011-10-03 05:13 UTC by Allison Karlitskaya (desrt)
Modified: 2011-10-14 14:22 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Allison Karlitskaya (desrt) 2011-10-03 05:13:42 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.
Comment 1 Matthias Clasen 2011-10-03 11:29:26 UTC
didn't you just add a guint64-taking variant ?
Comment 2 Allison Karlitskaya (desrt) 2011-10-03 12:54:45 UTC
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...
Comment 3 Matthias Clasen 2011-10-05 01:23:43 UTC
http://pubs.opengroup.org/onlinepubs/000095399/functions/pthread_cond_wait.html

has a rationale for why posix uses absolute times
Comment 4 Allison Karlitskaya (desrt) 2011-10-14 03:55:21 UTC
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).