SolarMutex: why & a sketch plan ...

[Noel Grandin]

On 2013-08-02 11:09, Stephan Bergmann wrote:
> 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...).

If we really want to run scripts in parallel, there is a safe and 
traditional way - run it in a separate process, communicating with the 
main process via UNO.

No locks required.

But I think that the benefits of being able to use scripts in parallel 
are so minimal that they don't even begin to compare with the 
maintenance cost of our current threading model.

We are much better off sticking with being single-threaded and focussing 
on improving the performance of our existing code.

Note that I'm not saying we should be completely and utterly 
single-threaded.
There are isolated situations where it will make sense to
(a) take copies of the required data structures
(b) spawn one or more worker threads
(c) when the computation is done, run a task on the main thread that 
updates the core data structures

And I'm speaking here as the (un)fortunate guy who gets to maintain a 
couple of medium-to-large desktop applications that talk to 2 or more 
different back-end servers at the same time, necessitating lots of 
threading.



Disclaimer: http://www.peralex.com/disclaimer.html