GTK+ 4.0 Gets More House Cleaning, Dropping Old Version References Saves ~7k L.O.C

[phoronix]

Phoronix: GTK+ 4.0 Gets More House Cleaning, Dropping Old Version References Saves ~7k L.O.C

Yesterday I wrote about GTK4 dropping the Mir display back-end in favor of the Wayland back-end. Additionally, the "big GDK lock" was also stripped out. The latest is some additional cleaning to lighten the tool-kit code-base by about seven thousand lines of code...

http://www.phoronix.com/scan.php?page=news_item&px=GTK4-House-Cleaning-Continues

[jrch2k8]

is nice seeing all the fat getting cut

[SyXbiT]

If it releases this fall, will the subsequent GNOME use GTK+ 4.0 for everything, and be called GNOME 4.0 ?

[ebassi]

If it releases this fall, will the subsequent GNOME use GTK+ 4.0 for everything, and be called GNOME 4.0 ?

No, it won't.

[parad0x]

If it releases this fall, will the subsequent GNOME use GTK+ 4.0 for everything, and be called GNOME 4.0 ?

There has to be a port of all the applications to actually use GTK+4 and hopefully a rewrite of gnome-shell.
Am I wrong on this last thing?
It was proposed to be internally redesigned AKA: option A. given all the good work on gtk+4 it would be the best thing!

https://wiki.gnome.org/Initiatives/Wayland/GnomeShell/GnomeShell4

[jacob]

If it's dropping the big GDK lock, does it mean that several threads will finally be able to issue API calls simultaneously?

[ebassi]

If it's dropping the big GDK lock, does it mean that several threads will finally be able to issue API calls simultaneously?

No, it doesn't. Only the thread that initialises and runs the main loop can access windowing system resources, and call toolkit API. That has always been the case. On X11 you could, in some cases, call GDK API from multiple threads — assuming you acquired the lock. That has never worked reliably or portably since the days of GTK+ 2.0.

[jacob]

No, it doesn't. Only the thread that initialises and runs the main loop can access windowing system resources, and call toolkit API. That has always been the case. On X11 you could, in some cases, call GDK API from multiple threads — assuming you acquired the lock. That has never worked reliably or portably since the days of GTK+ 2.0.

Now I'm confused. I always assumed that gdk_threads_enter() and gdk_threads_leave() were an official supported API. I also thought that "removing the big GDK lock" meant it will no longer be necessary.

[ebassi]

Now I'm confused. I always assumed that gdk_threads_enter() and gdk_threads_leave() were an official supported API.

They were deprecated in GTK 3.0, and their use heavily discouraged in GTK 2.0, once we added multiple backends.

I also thought that "removing the big GDK lock" meant it will no longer be necessary.

The GDK lock didn't do anything in GTK 3.0, unless you provided your own locking functions; this was necessary because applications like LibreOffice wanted to replace their own recursive main lock to the GDK one, to avoid re-entrancy issues.

In practice, though, marking critical sections in GDK never worked on Windows, for instance, and would lead to deadlocks. Even on X11, locking was a hit and miss, unless you knew exactly where to take the lock, and where GDK would take it.

The removal of the GDK lock makes it clear that it's never okay to call any GTK function from worker threads; if you want to update the UI from a thread, you should schedule a callback into the main loop, using the appropriate GLib API. Alternatively, you should use the GTask API that is part of GIO, and that guarantees to invoke the callbacks in the right thread.

[jacob]

The removal of the GDK lock makes it clear that it's never okay to call any GTK function from worker threads; if you want to update the UI from a thread, you should schedule a callback into the main loop, using the appropriate GLib API. Alternatively, you should use the GTask API that is part of GIO, and that guarantees to invoke the callbacks in the right thread.

I see, thank you for pointing that out.