The GNOME Foundation is supporting contributors with its fellowship program . You can help expand the fellowship program with a donation .

The previous month concluded with releasing the beta versions for GNOME 51. So this month, it was about time to get the bugs fixed in the beta releases.

Tales of a Dicey API

To give you a peek into my work, I’ll walk you through debugging an annoying issue. This problem had been floating around for a while during the GNOME 51 cycle. GNOME Shell was failing to load some of the app icons in the app grid. While I was pretty sure that the issue wasn’t the fault of libglycin, I finally decided to track down the problem myself. Luckily, running a nested GNOME Shell is pretty simple and well documented . Tracking down the key symptom was a question of systematic search. As it turned out, glycin was blocked as soon as it reached any asynchronous Gio.File operation. But why? Dumping the tracebacks of all the GNOME Shell threads via gdb gave an insight into Shell’s state: There were a lot of threads named pool-<n> , blocked on waiting for Gly.Loader.load to make progress. That’s exactly how Gio.Task names threads in its thread pool.

Hence, we had two important observations: Operations like Gio.File.open_async were not making progress. At the same time, there were a lot of threads on the Gio.Task thread pool that were stuck on calling Gly.Loader.load . Knowing more about GIO’s internals, this would immediately reveal the issue. Knowledge that I was lacking. I read GIO’s async documentation yet again, but I still couldn’t make sense of this behavior. Luckily, Sergey Bugaev and Sebastian Dröge immediately connected the dots: GIO’s async operations on Gio.File rely on the Gio.Task thread pool internally. However, the creation of new threads in the pool is heavily throttled . With that context, the issue became clear: GNOME Shell was trying to spawn as many threads as there are app icons via Gio.Task.run_in_thread , each thread waiting for a Gly.Loader.load call to return. For Gly.Loader.load to load the app icon from the disk, Gio.File.open_async would need a thread on the thread pool. However, as soon as the throttling allows the creation of a new thread, GNOME Shell would spawn yet another thread to load another app icon.

As far as I know, this interaction of the user-facing APIs like Gio.Task.run_in_thread and GIO’s async internals is not documented anywhere. Generally, just spawning as many threads on the task pool as possible is quite a fragile design decision, as it is hard to reason about and ensure that this is not starving other important operations from obtaining a thread on the thread pool. These are issues well known to some people. One suggestion has been to just remove or reduce the throttling of thread creation. However, designs like the one in GNOME Shell show that API consumers rely on the throttling, since otherwise, Shell might spawn in the order of hundreds of threads in one moment. There are also unsolved issues with memory management that go back to 2018. I think it is time to act on the conclusion that many people already had: This GIO feature is fundamentally broken. I have now proposed to deprecate the API.

After understanding the issue, something else clicked for me: I had seen issues with Nautilus mysteriously being stuck on file copy operations for a while. Now, that made sense: Nautilus was blocking the Gio.Task thread pool with loading thumbnails, running into the same issue as Shell. But not only were thumbnails not loaded, other Gio.File operations were blocked as well. While I previously thought about just fixing GNOME Shell by properly using libglycin’s async API directly, it now became obvious that far too many apps might rely on being able to occupy the complete thread pool. Hence, libglycin’s sync API would need a workaround for at least this cycle until the issues could be addressed properly in the API users. Glycin now tracks the information of something being a sync API call and then uses GLib’s sync APIs internally.

Hopefully, we can port our apps to using proper async APIs for GNOME 52.

Other Work

Of course, I worked on lots of other things this month. Here is a short overview.

Glycin

• • Fixed broken colors after editing a rare kind of JPEG where colors are encoded as RGB instead of YCbCr.
  • Allowed editing JPEGs with dimensions larger than 16,384 × 16,384 pixels. This was previously prevented due to accidentally using zune-jpeg’s default options in editing.
  • Added some missing API documentation.
  • Worked around a memory leak in gtk-rs’s gio::spawn_blocking . This issue has been fixed in a new gtk-rs release by now.
  • Finally merged the pixel density support in gdk-pixbuf’s libglycin shim.

Loupe

• • Fixed some issues with the new dialogs asking to save unsaved changes when editing.
  • Fixed a race condition when showing an edited image. This is still not completely behaving as intended and will need some more work during the GNOME 52 cycle.

Other Projects

• • Cleaned up the code for cargo-lock-analyzer . Also added an overview of Rust dependencies with security issues in our stack. This is still pretty experimental, and I’m thinking about how we can integrate this into a larger security tracking system for our dependencies.
  • Updated some apps to resolve open security issues. However, none of them seem to have any practical relevance for us.
  • Brought the proposal for an RFC process to the next step. It is now a merge request , following the RFC logic. Incorporated some of the feedback.

Outlook

This month was a bit slower than the previous month, since I worked some additional hours in July. Due to my disabilities , my contract is about the equivalent of a 1/3-position. I am very thankful that the Foundation has accommodated that. So my progress might be a bit slower in general.

For GNOME 52, there are exciting things ahead: Inkscape has ported their handling of raster graphics to libglycin. However, they still need CMYK and PNG interlacing support in libglycin to land the changes. This is something I will work on soon. For Loupe, there is an open merge request for saving images in different formats, which I’m looking forward to being completed.

Support the GNOME Project

The GNOME Fellowships are funded by our community. If you would like to help the GNOME project to stay sustainable, please consider donating .