On Tue, 2013-05-14 at 11:49 +0200, Stephan Bergmann wrote:
> Historically, the SolarMutex was assumed to be a clever solution to the
> problem of turning StarOffice from a single-threaded application to a
> multi-threaded one---lock the SolarMutex around any code that is not yet
> thread-safe, and be done with it. Or so people thought.
Hah :-)
> The world has long since found out that "single global mutex" is a
> horrible idea for GUI applications (where all GUI frameworks have
> settled on "confine relevant code to run in a single event-loop thread"
> instead).
Quite; then again - the next big, clever idea was to have highly
granular threading - with thread/re-enterancy hazards at every single
UNO method call :-) The combination of these two brainwaves makes
~everything a nightmare :-)
> This leaves us with completely unmaintainable ("where do I need to lock
> SolarMutex?"---"nobody knows for sure") and broken (cf.
> SolarMutexReleaser) code.
Right. So - here are the rules that I'm sticking to:
* anything that calls anything that does anything with vcl -
and anything that depends on / uses it needs to hold the
SolarMutex
* If you think you need to use the SolarMutexReleaser you
probably don't & seek expert help ;-)
The releaser is designed to fully drop the (recusive)
SolarMutex to allow another thread to take the toolkit
lock while we're waiting in the VCL main-loop. The VCL
main-loop does this itself FWIW.
=> in general if you grab the SolarMutex from another
thread, you will block until the (or sadly possibly
an inferior) main-loop is idle and then you can do
your work.
* Lock ordering is a nightmare - there is no lock ordering;
the whole threading situation is built on optimism and a
lack of rigour:
Luckily the SolarMutex is (almost always) held, so
in general, take it first: since that's almost
certainly a no-op ;-)
In terms of a sensible future for this, here is my crazy idealistic
plan (some of which overlaps with Kai's appartment work):
A give up pretending we're a multi-threaded application:
we are not - we are 1 + epsilon threaded.
B handle legacy UNO contracts relied on by StarBasic / Java etc.
around threading by pushing any UNO method on an object that
is not "on" the main-thread into an idle handler, and proxying
the return [ for now we could just take the Solar mutex there
- and call that 'entering the main appartment' ;-]
+ the apartment idea ~could/should do this.
C audit / retain the very-few pieces of code that are genuinely
thread-safe and actually useful that way: low-level pieces
of the UNO core, package2/ ucb/ configmgr2/ etc. seem
reasonably plausible: though locking clearly brings a per-call
cost.
D audit all non-UNO threads (there are not so many - IIRC there
was one in the gallery). Ensure that they are split into
non-GUI worker threads and idle callbacks
NB. our 'idle' story is -utterly- lame we need strong
priorities, instead of horrible fixed-time time-outs
cf. the unbelievable VCL re-size/paint timers ;-)
E remove all locking everywhere else ;-)
At this point we finally have a reasonably consistent and sensible
threading story :-) Then we can start to add threading where it actually
makes sense :-) [ something we actually need to do ] - and do it without
using any over-complicated, over-granular, and over-general solutions.
A few places where threading probably makes sense are:
+ the UNO core to meet back-compat guarentees
+ the calc computation core
+ image de-compression / scaling
+ splitting:
I/O -> unzip -> XML parse + namespage -> fast-parser
from - interpreting that XML in the core.
+ cores of applications from their rendering / presentation
[ this is a bigger one - use the Fennec approach to
have your zoom/pan/scroll code use rendered tiles of
document data produced by the "big uniprocess core" ]
[ this way you can make pan / scroll ultra smooth even
while the core is busy working ].
That at least would be my vision :-) I'd -love- help starting to get
there. Some parts of it can be worked on today with minimal pain.
D - for example would be easy and is nicely separable; indeed someone
building a list of all spawned threads, where they are spawned from, and
what they actually do across the code would be -really- nice and useful
to scope the work. Getting a good 'idle' story would probably help
responsiveness and rendering significantly too ... and is nicely
separable as a task :-)
HTH,
Michael.
--
michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
