SolarMutex: why & a sketch plan ...

[Lionel Elie Mamane]

On Thu, May 16, 2013 at 10:21:53AM +0100, Michael Meeks wrote:
> 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.

>> The world has long since found out that "single global mutex" is a
>> horrible idea for GUI applications (...)

> 	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

I don't have a clear picture of why VCL cannot take the SolarMutex
if/when it needs it, and how it can know "it should be held" but
"it is too late to take it now".

> 	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.

I don't see us as "only" an application in the first place, but also
as a programming platform for high-level stuff. Possibly that's more
of a database-centric view, but I've heard that "many" people (in the
financial sector) also use their spreadsheet in that way: very heavy
on programmability / automation (somewhat wrongly called "macros").

This view is not in direct contradiction with "1 + ε"-threaded: after
all, a programming platform that does not support multithreading is
still a programming platform. However, it is more onerous, because it
bottlenecks *all* software developed for/on top of our platform, and
not only our own application.

Besides, having a long-running / much work-doing Basic (or Python)
script running get in the way of doing Calc or Writer work is just
lame for the user. OTOH, crashing / giving wrong results "sometimes"
because of concurrency issues is even more lame, so I'm willing to go
"teetotal single-threaded" as a *transitory* situation. (Bottlenecking
all UI code in a single thread is something I have ~no opinion
on. I'll take your collective word on it being the thing that needs to
be done.))

> 	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.

> 	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.

So let's say that in my view, ideally non-UI scripts should be able to
run in parallel, including document manipulation (But possibly there
is no way to manipulate a document without binding it to an UI window
anyway?). I don't think that pushing locking on the script writer is
desirable (makes platform harder to program for, we are targeting also
the Basic/Python scripter, not only professional C++ hacker), nor
really feasible (UNO would have to provide a way to do locking in a
way that every language binding can access / use / cooperate...).

And *certainly* a script that calls purely stuff like the SDBC(X) API
should not be "artificially" bottlenecked into a single thread shared
with other such scripts, nor should it impact Writer / Calc / Impress
/ ... work when running in the background. In other words, my view is
that connectivity/source/drivers and dbaccess/source/core/api should
be "genuinely thread-safe and actually useful that way".

When I say "calls purely stuff like the SDBC(X) API", I have in mind
code that uses our programming platform as a cross-language equivalent
of ODBC / JDBC / ... on steroids (e.g. because we have Data Definition
Language abstraction), or, dare I say as a competitor to stuff like
DAO / ADOX / ...

-- 
Lionel