SolarMutex: why & a sketch plan ...

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.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot