On 06.01.21 14:56, Michael Meeks wrote:
Hi Julien,
On 18/12/2020 21:46, julien2412 wrote:
Gtk4 has been released 2 days ago, I know that migration from a version to
another version is not a 1 month work, but thought it could be interesting
and it can't hurt the current state of LO to begin to prepare it by
Unfortunately the gtk+ team removed the GDK_THREADS annotation that in
conjunction with the gdk_threads_set_lock_functions method I added back
in 2003 is/was at the core of our ability to use gtk+ safely with
threads and to share the SolarMutex with gtk+'s own mutex.
Checkout:
https://bugzilla.gnome.org/show_bug.cgi?id=793124
Quite possibly there is a better way to do this now; possibly by taking
a SolarMutexGuard in a very large number of places at the perimeter of
all gtk+ and a11y calls we could leave only smaller parts of the gtk+
backend as not thread-safe anymore.
Possibly we could come up with some clever I/O thread that would proxy
the X11 (or wayland?) protocol socket and wrap that with SolarMutex
protection - such that threading would continue to work.
Possibly we could move the things that use gtk4 into some 'appartment'
with some UNO magic - I guess the file-picker in particular. I fear
though that the new welding work assumes that we have a thread-safe gtk3
so we can construct, populate, script etc. UIs from any thread.
hmm... isn't this basically the same situation as the macOS and the Qt
VCLplugs? they have a way to transfer widget work to the main thread,
see implementation of Qt5YieldMutex and osx/salinst.cxx SalYieldMutex;
this is all based on a design by jmux.
the relevant bug for Qt5 was about Wollmux extension calling from
non-main threads:
https://bugs.documentfoundation.org/show_bug.cgi?id=119856
This is quite a big engineering problem, that needs very significant
thought, and will create threading problems that give and give.
The up-side for the gtk+ maintainers is only that they don't have ~100
gdk_threads_enter/leave calls that they had to think about in their
code-base.
In any world where the gtk+ authors also wrote large apps, I would hope
that they would not make decisions that so carelessly traded a few
minutes per year of their time for spending man-months of other people's
and whole new classes of bugs for millions of users.
well i guess by "large apps" you mean LO, because hopefully nobody else
was dumb enough to f*ck up threading architecture in a GUI app to the
extent the StarOffice developers have.
Unrelenting platform churn is one of the supposed benefits of FLOSS
development though ... but the up-stack bit-rot is a pretty serious
thing to fight.
Then again - doing work to use more modern APIs sounds sensible -
assuming that they are not too modern (I guess lots of them tend to get
added when they developed gtk4 which is really very recently for those
who care about APIs >6 months old ;-)
HTH,
Michael.
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice
