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 477659 - The "g_main_context_check" interface ignores it's "max_priority" parameter
The "g_main_context_check" interface ignores it's "max_priority" parameter
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: mainloop
2.14.x
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2007-09-17 05:04 UTC by Areg Beketovski
Modified: 2018-05-24 11:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
The test case reproducing the bug (3.46 KB, text/plain)
2007-09-17 05:06 UTC, Areg Beketovski
Details

Description Areg Beketovski 2007-09-17 05:04:52 UTC
Please describe the problem:
Documentation states that "max_priority" input parameter of the interface g_main_context_check determines "the maximum numerical priority of sources to check". This means that all the sources with numerical priority higher than "max_priority" should not be checked, although in the implementation this parameter is ignored.

Steps to reproduce:
1.  3 sources are attached to the context, with the priorities {-1, 0, 1}
2. All the sources, added to the context return FALSE upon prepare*() and check*() calls
3. Verify that return value of the g_main_context_check() is FALSE
4. Verify that the only source, that was checked was the one with priority -1, [max_priority == -1]

g_main_context_check interface checks (actually calls the check*() function of the given source) all three sources, regardless of their numerical priority value.

Actual results:


Expected results:


Does this happen every time?
Yes

Other information:
The detailed bug description can be found at: 

http://linuxtesting.org/results/report?num=D0004
Comment 1 Areg Beketovski 2007-09-17 05:06:01 UTC
Created attachment 95706 [details]
The test case reproducing the bug
Comment 2 Dan Winship 2014-02-16 15:42:39 UTC
So this is easy to fix:

diff --git a/glib/gmain.c b/glib/gmain.c
index 6bb726e..bc95bff 100644
--- a/glib/gmain.c
+++ b/glib/gmain.c
@@ -3537,7 +3537,7 @@ g_main_context_check (GMainContext *context,
     {
       if (SOURCE_DESTROYED (source) || SOURCE_BLOCKED (source))
        continue;
-      if ((n_ready > 0) && (source->priority > max_priority))
+      if (source->priority > max_priority)
        break;
 
       if (!(source->flags & G_SOURCE_READY))

and that doesn't affect glib's usage of the function at all (because g_main_context_iterate() only passes a max_priority less than G_MAXINT if g_main_context_prepare() found a source that was already ready). But if other people are calling g_main_context_check() directly (eg, people trying to integrate glib sources with another main loop) then it might break them.

The other possibility would be to just change the docs to reflect the way that it has always worked:

--- a/glib/gmain.c
+++ b/glib/gmain.c
@@ -3478,12 +3478,16 @@ g_main_context_query (GMainContext *context,
 /**
  * g_main_context_check:
  * @context: a #GMainContext
- * @max_priority: the maximum numerical priority of sources to check
+ * @max_priority: unused
  * @fds: (array length=n_fds): array of #GPollFD's that was passed to
  *       the last call to g_main_context_query()
  * @n_fds: return value of g_main_context_query()
  * 
  * Passes the results of polling back to the main loop.
+ *
+ * The @max_priority parameter is not used; g_main_context_check()
+ * will check all priority levels, in order, until it finds one with
+ * sources that are ready to dispatch.
  * 
  * Return value: %TRUE if some sources are ready to be dispatched.
  **/
Comment 3 GNOME Infrastructure Team 2018-05-24 11:06:00 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: https://gitlab.gnome.org/GNOME/glib/issues/105.