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 733342 - maincontext: Add a way to ensure one (and only one) source is dispatched per iteration
maincontext: Add a way to ensure one (and only one) source is dispatched per ...
Status: RESOLVED NOTABUG
Product: glib
Classification: Platform
Component: mainloop
2.41.x
Other All
: Normal enhancement
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2014-07-17 22:09 UTC by Mathieu Duponchelle
Modified: 2014-11-10 16:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Implements the proposed enhancement (4.99 KB, patch)
2014-07-17 22:09 UTC, Mathieu Duponchelle
rejected Details | Review

Description Mathieu Duponchelle 2014-07-17 22:09:00 UTC
Created attachment 281047 [details] [review]
Implements the proposed enhancement

Allows to specify the maximum number of sources dispatched by one
call to g_main_context_iteration () and adds a test case.
Comment 1 Thibault Saunier 2014-07-18 19:19:56 UTC
The use case here is that we run the maincontext ourselves, and we need to make sure that we can "pause" the thread (it is a GstTask) after each and every GSource dispatch. We looked at the API but there seem to be no way to do that, thus this API addition.

Also can you think of any workaround so we could avoid to depend on an API that is not even in the GLib right now?
Comment 2 Thibault Saunier 2014-08-15 16:13:00 UTC
Could you please give some feedback on that bug?

It has been discussed during the GUADEC and it I think you actually agreed that something was not totally right about the current behavior (as demonstrated by a simple test Benjamin Otte wrote at that time).
Comment 3 Allison Karlitskaya (desrt) 2014-08-18 13:54:22 UTC
Review of attachment 281047 [details] [review]:

I'm fairly sure we don't want to take this approach.
Comment 4 Allison Karlitskaya (desrt) 2014-08-18 14:00:09 UTC
So here's the problem here: if we dispatch only one source per mainloop run then we can get into a problem where that source will starve all other sources at the same priority level.

This is because of a long-standing principle that we always dispatch sources in the order that they were registered.  In-order dispatch of idle sources, for example, is heavily relied on by at least GDBus and probably many other things.

If we have only one dispatch per iteration then we will continue dispatching the first source over and over again.

In a discussion with Benjamin I think we managed to convince ourselves that we really only care about strict ordering for the first dispatch.  If the source survives past that first dispatch then we could move it to the end of the list of sources at its priority level to give the others a higher chance for next time.

Once we did that, we could consider adding a "check and dispatch only one" API.  I definitely don't want to add a "max dispatches" state to the GMainContext, however.

This change is somewhat dangerous, in my opinion, since changing the order in which various bits of a program run is a great way to cause new bugs to pop up.  The only thing that makes me think that this is safe at all is the already-semi-non-deterministic nature of mainloop dispatching.  What's worrying, however, is that introducing the new API would effectively prevent us from ever reverting this change if we discovered it to be problematic.
Comment 5 Thibault Saunier 2014-11-10 16:32:15 UTC
OK, we decided not to use GMainLoop to solve our issue but have custom code instead. Closing that bug as NOTABUG.