GNOME Bugzilla – Bug 680102
Make GWakeup public again
Last modified: 2018-05-24 14:22:08 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).
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.
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.
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().
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").
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...
(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...
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...
-- 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: https://gitlab.gnome.org/GNOME/glib/issues/575.