Hi there,
Turns out the silly deadlock we see on XLSX loading is a result of the
windows' "Yield" implementation being simply awful[1] ;-) The progress
bar will deadlock vs. the main-loop in this case.
So - what can we do ? :-) interestingly the 'Yield' drops the solar
mutex all over the place inside our filters at random places already
today - so I'm no longer concerned about that: which is encouraging.
Separately - we wanted to put the progress bar updates into a thread -
and we should do that in the main thread I think.
That's actually not that hard to do IMHO; so instead of
(sc/source/filter/oox/workbookfragment.cxx):
{
// Ideally no-one else but our worker threads can re-acquire that.
// potentially if that causes a problem we might want to extend
// the SolarMutex functionality to allow passing it around.
SolarMutexReleaser aReleaser;
aPool.waitUntilWorkersDone();
}
We can drop the comment - there is no new risk here. And instead of the
'SolarMutexReleaser' we should just run an inferior main-loop and we
don't even need any explicit locking - the SolarMutex should do that for
us ;-)
ProgressBarTimer aTimer;
while (mnWorkingThreads > 0) {
Application::Yield();
}
aPool.waitUntilWorkersdone();
And the ProgressBarTimer - should just update and re-render the timer
every 500ms or so.
As a side-effect / bonus this should let other LibreOffice applications
continue working while long sheet loading is occurring ;-) which might
be nice - but is no more risky than the current scattering of 'Yield's
we have everywhere.
Oh - and of course, in this mode - we need to tweak the
WorksheetGlobals::setRowModel() thing to not fiddle with the global oox
SubSegment::setPosition thing - but do that in the main loop. Instead I
guess we should have some atomically written sal_Int32 nStepsDone;
variable or something that the threads update and continue working ASAP
- without rendering anything - the 500ms timeout in the main thread will
handle that.
The mnWorkingThreads should be updated by the ThreadWorker when they
exit I guess.
How does that sound ?
hopefully it kills our windows deadlock without having to de-bong the
craziness in[1] for 4.2 :-)
At least that's one idea,
ATB,
Michael.
[1] -
http://cgit.freedesktop.org/libreoffice/core/tree/vcl/win/source/app/salinst.cxx#n681
is reasonably amazing, not only the 'sleep (1);' but also the assumption
that the main thread is not (eg.) doing a thread.join(); on a thread trying
to do something with the GUI & => will never return.
--
michael.me...@collabora.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
