SolarMutex: why & a sketch plan ...

[Michael Meeks]

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