Hi Noel,
On Wed, 2013-12-04 at 14:13 +0200, Noel Grandin wrote:
> But perhaps there is a way to get there that does not require
> - genius-level IQ
> - years of LO experience
> - tons of time
:-) heh; so - I think anything that involves comprehensively
understanding the threading problems we have across Java, StarBasic, the
VCL core+gtk+/Qt/Windows/Mac backends, COM, UNO, URP et. al. is going to
require some serious thought ahead of time.
I'm a bit nervous of incrementally moving in a direction, when we don't
know what the best direction actually is =)
Having said that - there are -some- obvious things (as you say) that we
can do, to lay the groundwork that are necessary anyway.
One of those is (I think) fixing the main-loop so we have real,
properly prioritized asynchronous callbacks, reasonably usable message
passing interfaces with the UI thread, some sane closure API etc.
Ideally if we're going to have a 'UI thread' as a core concept, that'd
be reflected in sal/ and we'd encourage UNO method bridging into that
thread.
> (*) gradually fix the places that assert until we get to a point where
> we can make the option always on in debug mode.
I'm really not convinced that a piecemeal solution is possible here
without sitting down and wrestling with / understanding all of the
problems and planning a real solution. In the short-term the "one big
lock" of the Solar Mutex is incredibly more sane, safe, sensible and
tractable than the myriad superstition-based, un-tested locking patterns
mixed with poor API design that we see almost everywhere else in the
code.
I'm also deeply under-convinced by the "Use UNO for everything, and the
apartment model solves everything" meme that was the previous great
white hope. That seems to me to be a usability, readability,
maintainability, comprehensibility disaster area - combined with an
emphasis on inefficient and problematic highly granular (per method)
locking so ... ;-)
Personally, I'm not confident in any obviously good direction to go in
incrementally to fix the mess. The idea of fiddling with the solar mutex
such that we can tell when other threads actually take/release it is a
good one - yet there's not fundamentally a problem with having one big
lock [ at least as a transition ], nor with using threads safely: we've
got some significant wins in the XLSX import like this eg.
The scripting idea sounds interesting, and this ties into some of the
apartment ideas that were mooted before; but quite how to integrate the
idea of bridging to a main thread - when that main thread may not even
own the SolarMutex (or may be blocked on it) in itself requires some
thought & design.
So - I'm not convinced that there is any substitute for real thought
and planning on this one; though hopefully (having done that) we can get
an incremental approach that will parallelise and work well.
ATB,
Michael.
--
michael.me...@collabora.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
