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

On 2013-05-16 11:21, Michael Meeks wrote:
>         Right. So - here are the rules that I'm sticking to:
>
>         + splitting:
>                 I/O -> unzip -> XML parse + namespage -> fast-parser
>                 from - interpreting that XML in the core.
Personally I think that using a pull-style unzipper and xml-parser would 
be just as fast, and way simpler to debug.

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

Rather than find threading issues by hand, we could abuse the existing code:
(a) define a special configure flag --find-bad-ui-threading
(b) when compiled in that mode, change the SolarMutex code so that it 
whinges loudly if acquired from outside the event thread
(c) Run LO unit tests
(d) Fix places which complain

Obviously, the above is the part I can't do.
But I (and other similarly not-skilled hackers) could help with the 
fixing if someone else could create the checking code and write up some 
basic instructions on how to
(a) create a new thread using the "LO way"
(b) push a result task onto the LO event thread (you seem to call it the 
idle thread??)


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