GNOME Bugzilla – Bug 733342
maincontext: Add a way to ensure one (and only one) source is dispatched per iteration
Last modified: 2014-11-10 16:32:15 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.
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?
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).
Review of attachment 281047 [details] [review]: I'm fairly sure we don't want to take this approach.
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.
OK, we decided not to use GMainLoop to solve our issue but have custom code instead. Closing that bug as NOTABUG.