If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Announcement

Collapse

No announcement yet.

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

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...

Comment

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/W...ll/GnomeShell4

Comment

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.

2 likes

Comment

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.

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.

1 like

Comment

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.