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 657729 - modernise GMainLoop
modernise GMainLoop
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: mainloop
unspecified
Other All
: Normal enhancement
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2011-08-30 15:51 UTC by Allison Karlitskaya (desrt)
Modified: 2013-01-15 19:11 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Allison Karlitskaya (desrt) 2011-08-30 15:51:13 UTC
there are a few major changes that we should make to GMainLoop:

 - race-free with respect to signals
 - microsecond accurate
 - not O(n)
 - possibility of edge-triggered event sources


Set the edge-triggered event sources thing aside for a moment since it's pretty extremely complicated, and consider the others.  The biggest thing standing in the way is the existing GSource API.  Mostly for two reasons:

 - each source expects to be polled each time (which is O(n))
 - the source prepare function returns a time in milliseconds

It seems that we could easily fix quite a lot of problems with two relatively minor API tweaks:

  1) Add a g_source_set_wakeup_time() to allow setting an absolute monotonic
     time (in microseconds) at which the source should be woken up.

  2) Allow the possibility of having the check/prepare functions given as
     NULL to mean "don't poll this source, but only dispatch it when one
     of its pollfds is ready or when its wakeup time has been reached".


Internally, we would separate sources into two lists: those with the check/prepare functions and those without.  On a mainloop iteration, we'd treat the sources with check/prepare in the same way as we do now, and completely fail to visit the ones without.  Then we're only O(n) in terms of sources that use the old API.
Comment 1 Dan Winship 2011-08-30 16:11:56 UTC
(In reply to comment #0)
>  - not O(n)

see also bug 143061 and bug 619329
Comment 2 Matthias Clasen 2011-08-30 22:41:29 UTC
I think I've asked this in the past, but it would be nice first step to gather some data on what n we are actually talking about here, in average apps.
Comment 3 Allison Karlitskaya (desrt) 2011-08-30 23:10:00 UTC
From a practical standpoint, in our applications, it's quite small: no bigger than 20 at most, I'd say.

Our O(n) behaviour is often cited for why people don't use GLib in some other types of applications, though.
Comment 4 Allison Karlitskaya (desrt) 2011-08-31 02:29:00 UTC
I've pushed a few commits to the 'wip/source-api' branch in case anyone is interested.
Comment 5 Matthias Clasen 2011-08-31 04:05:32 UTC
Also see bug 156048
Comment 6 Allison Karlitskaya (desrt) 2013-01-15 19:11:12 UTC
The API changes that this bug was intended to introduce have been merged to master.  When we actually want to use this to support epoll, we can look at the other bug.