Hi *,
Am 12.03.21 um 12:16 schrieb Michael Meeks:
We've recently had problems with dialogs running in Online Kit
processes that are not cleaning up properly when the process is asked
to quit by the core.
The proximate fix is/was to hard kill the remote process =)
but - I'd love to do better if possible.
... regression?
If you see vcl's:
Dialog::Execute () ...
// Yield util EndDialog is called or dialog gets destroyed
// (the latter should not happen, but better safe than sorry
while ( !xWindow->IsDisposed() && mbInExecute )
Application::Yield();
You see one of these:
while (condition)
Application::Yield();
archetypes. Of which there a dozen+ scattered around the code eg.
sfx2/source/doc/printhelper.cxx- while( m_pPrinter->IsPrinting() )
sfx2/source/doc/printhelper.cxx: Application::Yield();
etc. etc.
Not least because Application:Yield becomes an instant-return when
we're trying to quit. So - we could add a flag:
while (condition && !(new Application::mbAppQuit accessor))
to all suspicious looking call-sites.
Perhaps it'd be nicer to have a:
Application::YieldWhile([]{ return m_pPrinter->IsPrinting(); });
or somesuch - so we can add that this just once (?)
There is also:
static void Quit();
static void EndYield();
so we can add
bool Application::IsQuit()
{
return ImplGetSVData()->maAppData.mbAppQuit;
}
From my POV and your example, whatever IsPrinting is testing (I assume
some thread or OS API), should return earlier / cancel processing /
check IsQuit / imply called EndYield. I don't think trying to "beef up"
Application::Yield in whatever direction will help, but might introduce
other problems, like un-joined threads, missing cleanup and whatnot.
Adding a !Application::IsQuit to a yield loop, might be the right fix in
some cases, but not generally. Application::Quit already sets mbAppQuit
and calls PostUserEvent to wake up yield.
JMG
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice
