07f8a5daa3
As commit44616ebafd('gmain: More explicitly document g_main_context_release() prereqs') correctly notes, you need to have the context acquired before releasing it (just like a ref must match an unref). Commit3926af723a('gmain: Add precondition assertions to g_main_context_release()') then goes one step further, and requires that the calling thread is also the owner (the thread, that acquired the context). This is something which has been documented by g_main_context_release() for years: > Releases ownership of a context previously acquired **by this thread** With acquire/release and g_main_context_is_owner() we track the thread that acquired the context. That is mainly useful for asserting correctness to not accessing the context from an unexpected thread. Note that g_main_context_acquire() returns FALSE and does nothing when the context is already acquired from another thread. Methods like g_main_context_{prepare,query,dispatch}() require that the calling thread is the owner (although, they don't assert for that, which they maybe should). With the assertion, it means you cannot pass an acquired context to another thread for release. Obviously, if you pass on an acquired context to another thread, the only next thing you can do is g_main_context_release() (no acquire,prepare,query,dispatch). But it's still useful to be able to release it, and to be able to keep it acquired for a prolonged time. libnm needs that, as it integrates a GMainContext into another GMainContext. For that, it needs to acquire the inner context and keep it acquired for as long as the context is integrated. Otherwise, when a source gets attached to the inner context, the inner context is not woken up (see g_source_attach_unlocked()). In commite26a8a5981('Add G_MAIN_CONTEXT_FLAGS_OWNERLESS_POLLING'), a flag was introduced to solve that same problem, without keeping the inner context acquired all the time. Note that G_MAIN_CONTEXT_FLAGS_OWNERLESS_POLLING is a flag of the GMainContext, so it only works if the user who integrates the inner context also controls how the context was created. For libnm, having the inner context acquired at all times is no problem, because it's understood that the user gives up agency on the inner context while it's integrated. The only thing to consider is that the outer context might be iterated on another thread. When calling prepare,query,dispatch on the inner context, the code will notice it, release the inner context and re-acquire it on the new thread ([1]). This works just fine, but it requires that g_main_context_release() works from any thread. So, in order to not break NetworkManager, let’s drop the ownership assertion. However, NetworkManager is strictly breaking the API contract here, and GLib reserves the right to re-add this assertion in future. Still keep the assertion for the owner_count. (Commit and commit message significantly updated by Philip Withnall; all errors are his.) [1]9f01cff04f/src/libnm-glib-aux/nm-shared-utils.c (L4944)Related:3926af723a('gmain: Add precondition assertions to g_main_context_release()') Related:c67dd9d3fe('gmain: Add a missing return on error path in g_main_context_release()') Closes #3054
GLib
GLib is the low-level core library that forms the basis for projects such as GTK and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system.
The official download locations are: https://download.gnome.org/sources/glib
The official web site is: https://www.gtk.org/
Installation
See the file ‘INSTALL.md’. There is separate and more in-depth documentation for building GLib on Windows.
Supported versions
Only the most recent unstable and stable release series are supported. All older versions are not supported upstream and may contain bugs, some of which may be exploitable security vulnerabilities.
See SECURITY.md for more details.
Documentation
API documentation is available online for GLib for the:
Discussion
If you have a question about how to use GLib, seek help on GNOME’s Discourse
instance. Alternatively, ask a question
on StackOverflow and tag it glib.
Reporting bugs
Bugs should be reported to the GNOME issue tracking system. You will need to create an account for yourself. You may also submit bugs by e-mail (without an account) by e-mailing incoming+gnome-glib-658-issue-@gitlab.gnome.org, but this will give you a degraded experience.
Bugs are for reporting problems in GLib itself, not for asking questions about how to use it. To ask questions, use one of our discussion forums.
In bug reports please include:
- Information about your system. For instance:
- What operating system and version
- For Linux, what version of the C library
- And anything else you think is relevant.
- How to reproduce the bug.
- If you can reproduce it with one of the test programs that are built
in the
tests/subdirectory, that will be most convenient. Otherwise, please include a short test program that exhibits the behavior. As a last resort, you can also provide a pointer to a larger piece of software that can be downloaded.
- If you can reproduce it with one of the test programs that are built
in the
- If the bug was a crash, the exact text that was printed out when the crash occurred.
- Further information such as stack traces may be useful, but is not necessary.
Contributing to GLib
Please follow the contribution guide to know how to start contributing to GLib.
Patches should be submitted as merge requests to gitlab.gnome.org. If the patch fixes an existing issue, please refer to the issue in your commit message with the following notation (for issue 123):
Closes: #123
Otherwise, create a new merge request that introduces the change. Filing a separate issue is not required.