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 680102 - Make GWakeup public again
Make GWakeup public again
Product: glib
Classification: Platform
Component: mainloop
Other All
: Normal normal
: ---
Assigned To: gtkdev
Depends on:
Reported: 2012-07-17 14:33 UTC by Dan Winship
Modified: 2018-05-24 14:22 UTC
See Also:
GNOME target: ---
GNOME version: ---

Make GWakeup public again (12.87 KB, patch)
2012-07-17 14:33 UTC, Dan Winship
none Details | Review

Description Dan Winship 2012-07-17 14:33:14 UTC
I did this because I wanted to use it in glib-networking, though I've
realized I can cheat and use a GCancellable instead, so I don't
actually *need* this. But we'll presumably want to do this at some
point anyway.

Making GWakeup public made it harder to play games with gwakeup.c for
the test programs, so I changed how they worked (and additionally
added an assertion to make sure that the eventfd test case is really
getting an eventfd and the fallback version is really not).
Comment 1 Dan Winship 2012-07-17 14:33:16 UTC
Created attachment 219027 [details] [review]
Make GWakeup public again

The API has stayed the same since we first added it, so let's let
everyone else in on the fun now too.
Comment 2 Allison Karlitskaya (desrt) 2012-07-17 15:30:26 UTC
I'm mildly against this proposal -- particularly since we don't have a real user.

In particular, I have a future scenario in my head where we may not use GWakeup anymore:  we rewrite the mainloop and base all timer-based sources (using a new set_expiry_time() API, not the existing prepare/check approach) off of a timerfd.  We can then wake the mainloop by setting this timerfd to fire immediately instead of having a separate object that we use only for wakeups.
Comment 3 Allison Karlitskaya (desrt) 2012-07-17 15:32:17 UTC
Also: in the distant future, if we go totally legacy free (removing all prepare/check code) and use epoll then it's possible that we may never need to explicitly wake the mainloop at all.  We can add new timeout or fd-based sources from other threads without needing to re-poll().
Comment 4 Dan Winship 2012-07-17 15:55:21 UTC
Well, if we make it public and it's actually useful to people, then it doesn't matter whether GMainContext keeps using it or not.

And GCancellable is currently implemented via GWakeup too.

The place I'm using it, I basically want a cancellable version of g_cond_wait(). This is easy to do with GWakeup; get the fds from the GWakeup and the GCancellable, and poll until one of them is ready. As I said above, I can cheat by using another GCancellable as the "wakeup". It's just ugly, because the names don't correspond to what the code is doing (eg, using g_cancellable_cancel() to mean "wake up the waiting thread").
Comment 5 Allison Karlitskaya (desrt) 2012-07-17 16:39:24 UTC
I'm not thrilled about GCancellable being implemented using GWakeup, either.  I'd much rather we didn't have to have an fd-per-cancellable.  We've seen a few cases of this causing apps to run out of fds...
Comment 6 Dan Winship 2012-07-18 12:47:46 UTC
(In reply to comment #4)
> The place I'm using it, I basically want a cancellable version of
> g_cond_wait(). This is easy to do with GWakeup

Ryan pointed out on IRC that this could just as easily be done by using a GCond and calling g_cond_signal/broadcast() from the "cancelled" signal handler. Then I said that I need to be able to wait for the signal asynchronously, and he pointed out that *that* could also be done without an fd, which led to us changing how GCancellableSource works in bug 680121.

Then I clarified that I need to be able to wait synchronously *or* asynchronously, and sometimes both at the same time from two different threads, and he agreed that having something fd-based was convenient for that. ("to replace it you'd need (at least) a lock, a gcond, a gmutex and a gslist of gmaincontexts".) Though if that was hidden away in a helper class (GWakeable?) it at least wouldn't be externally ugly...
Comment 7 Allison Karlitskaya (desrt) 2012-07-18 13:13:02 UTC
I might be happier with a GWakeable that was based on GMainContext and didn't use any fds.

It's worth noting that this is substantially equivalent to GCancellable with the exception that I don't think GCancellable supports the synchronous wait-in-place.

We would, however, be prevented from rebasing GCancellable on it because GCancellable has the (legacy?) fd abilities...
Comment 8 GNOME Infrastructure Team 2018-05-24 14:22:08 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: