Re: SolarMutex: why & a sketch plan ...

On 07/31/2013 01:16 PM, Lionel Elie Mamane wrote:
> 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".

Scriptability makes threading a hard problem.  The approach taken by 
UNO, making the implementation of every method call responsible for 
being thread safe, leads to unnecessarily slow and generally 
incorrect-anyway code, of course.  But exposing synchronization 
facilities in the scripting API, though theoretically being a correct 
approach, is obviously not what customers of that scripting API want, 
either.  And using just a single thread apparently has drawbacks, too.

Even if we had reached a state where a script can manipulate a single 
document's model and do so without taking care of any threading issues, 
because the script is confident that it is the only entity manipulating 
that model, and LO would be able to respond to changes to that model by 
updating its view(s) in a threadsafe way --- even that would not be good 
enough probably.  Because if it ever /did/ happen that there are 
multiple manipulators of a single document model after all, it would be 
all to likely that their parallel manipulations would not only lead to 
garbled content (which might be considered acceptable), but also to 
crashes (when, say, one script's code leads to a delete of a C++ struct 
still accessed via another script's code).

(In a way, multiple scripts accessing a single document model in 
parallel is very similar to collaborative editing.  So if we manage to 
get the scripting API's level of granularity and underlying 
implementation right, so that any individual, yet semantically 
meaningful operation on the model is done in a thread-safe way --- by 
"internal locking" just like the current UNO API prescribes --- then 
that might indeed be a sweet spot we want to reach:  Scripts don't need 
to worry about threading, and if multiple actors should ever happen to 
manipulate the same document in parallel, we will have the conflict 
resolution in place we want to have for collaborative editing anyway.)

Stephan, dreaming in the sun outside guadec