Kay Ramme - Sun Germany - Hamburg wrote:
> Agreed, what about dropping support for "gdk_threads_set_lock_functions"
> then and to always acquire (which AFAIK is already the case for Gnome <
> 2.4) the GDK mutex (gdk_threads_enter / ..._leave) before calling into
> GDK? You are actually right, that from a coding standpoint the
> difference isn't too big, but it IMHO is from testing point of view.
Michael's idea was that we should have a guranteed way of synchronizing
the lock count between gdk mutex and solar mutex. In theory dispatching
events (in multiple threads) could let you end up with a lock count that
is different from the gdk lock count, perhaps leaving you with a locked
solarmutex but actually unlocked gdk and/or vice versa. This would not
be a problem with in vcl itself, but as soon as you have other gtk based
in process services (like the file dialog or a gnome-vfs based UCB
content provider, a gtk based GUI from a theroetical UNO service), this
would probably lead to problems, because these would call the gtk
dispatch functions themselves which would then (being the same gtk
instance) dispatch also events to vcl; which now would acquire the solar
mutex again and gets out of sync with the gdk mutex; resulting in
probable deadlock.
Since at the time (and probably still) this is a rather rare problem, we
kept 2.2 (not quite so old at the time) alive and had the secure
synchronizing mechanism from 2.4 upwards with basiclly no extra cost.
Just my 2 cents, pl
--
If you give someone a program, you will frustrate them for a day;
if you teach them how to program, you will frustrate them for a lifetime.
-- Author unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
