Effort/Make Dialogs Asynchronous

As we proceed with the UNO Threading Framework, it becomes necessary to fix asynchronous dialogs so as to avoid deadlocks. This page documents the background, necessary tasks and their status. Thanks to Kai Sommerfeld for providing this information.

Typical Changes - Example

IMO a simple example for the code changes typical for asyncdialog can be found in /svx/source/dialog/cuigaldlg.cxx and the respective header file in the same directory.

There is a class SearchProgress which creates an instance of class SearchThread. The SearchThread worker thread calls back into VCL (e.g. SearchThread::ImplSearch(): mpBrowser->aLbxFound.InsertEntry()).

In asyncdialogs the latter will lead to a deadlock, because:

• The thread that calls SearchProgress::Execute() thereby enters the Office Mutex threading environment
• That thread stays there at least until Execute() returns.
• But Execute() will never return, because it waits for the SearchThread to end.

In fact it waits indefinetly that CleanUpHdl will be called (handler calls EndDialog() and this will let Execute() return), which is only done from inside SearchThread::onTerminated(). But the worker thread only terminates if it is ably to deliver search results to VCL, but it will never be able to do so because every VCL call will automatically guarded by the Office Mutex threading environment...

The solution was to switch to the new asyncdialog VCL Dialog execution API.

To DO

List of things to do in CWS asyncdialogs

General

• Find and change all dialogs that are executed via Dialog::Execute() and that indirectly or directly spawn threads that need to call back to non-threadsafe code (for example VCL API, non-threadsafe UNO objects) in order to get the dialog finished.
  • VCL: deprecate Dialog::Execute() => changes mail!
  • UNO: deprecate css::ui::dialogs::XExecutableDialog => changes mail!

Affected dialogs

• unopkg binary -- gui mode
  • desktop/source/deployment/gui/dp_gui_service.cxx => ServiceImpl::execute()
  • dialog creates threads.
  • dialog is a non-threadsafe UNO service => does not use Dialog::Execute, but Application::Execute()
    • BUG: Application::Execute() enters apartment at the beginning and remains in apartment all the time
    • dialog worker threads will never be able to enter apartment => deadlock
    • UTF2: Application::Execute() must be fixed - DONE (by KR)
    • asyncdialogs: com.sun.star.comp.deployment.ui.PackageManagerDialog service: - does no longer implement XExecutableDialog, but XAsynchronousExecutableDialog DONE: changed

• fpicker/source/unx/gnome/asynceventnotifier.hxx: #include <osl/thread.hxx>
  • triggered by dialog - ./fpicker/source/unx/gnome/SalGtkFilePicker.cxx => SalGtkFilePicker::execute()
  • 'execute' problem must be solved
  • DONE: no change (asynceventnotifier no longer used in m124)

• svtools/source/control/inettbc.cxx:#include <vos/thread.hxx>
  • triggered by misc dialogs using SvtURLBox => 'execute' problem must be solved
  • class XMLFilterTabPageXSLT (/framework/filter/source/xsltdialog/xmlfiltertabpagexslt.hxx)
    • @@@ todo => investigate if change needed
  • class SvxIMapDlg (/graphics/svx/inc/imapdlg.hxx)
    • @@@ todo => investigate if change needed
  • class SvxHyperURLBox : public SvtURLBox (/graphics/svx/source/dialog/hltpbase.hxx)
    • @@@ todo: callers? => investigate
  • class OFileURLControl : public SvtURLBox (/graphics/svx/source/dialog/urlcontrol.hxx)
    • @@@ todo: callers? => investigate
  • class AddInstanceDialog (/graphics/svx/source/inc/datanavi.hxx)
    • @@@ todo => investigate if change needed
  • class SvtExpFileDlg_Impl (/gsl/fpicker/source/office/iodlgimp.hxx)
    • part of implementation of class SvtFileDialog (/gsl/fpicker/source/office/iodlg.hxx)
    • lots of direct and indirect callers!
    • @@@ IN PROGRESS (Peter Burow)
  • class ScLinkedAreaDlg (/sc/sc/source/ui/inc/linkarea.hxx)
    • @@@ todo => investigate if change needed
  • class FileURLBox : public SvtURLBox (/util/svtools/inc/fileurlbox.hxx)
    • @@@ todo: callers? => investigate
  • class OFileURLControl : public SvtURLBox (/util/svtools/inc/urlcontrol.hxx)
    • @@@ todo: callers? => investigate
    • IN PROGRESS

• sw/source/ui/inc/maildispatcher.hxx:#include <osl/thread.hxx>
  • class MailDispatcher (sw/source/ui/inc/maildispatcher.hxx) is an osl::Thread
    • Instances are created in:
      1. sw/source/ui/dbui/dbmgr.cxx
      2. sw/source/ui/dbui/mailmergechildwindow.cxx
    • MailDispatcher has interface for regsistration of UNO listeners
      1. no Dialog::Execute in any possible callstack (currently only reachable via UNO API) ==> DONE: no change needed
      2. SwMailSendDialog is a modeless dialog, does not need to be changed therfore, but is called by MailMergeWizard which has overridden Dialog::Execute()
      • • MailMergeWizard and calling code must be changed ==> DONE: changed
  • DONE

• svx/source/dialog/cuigaldlg.hxx:#include <vos/thread.hxx>
  • @@@ triggered by dialog => 'execute' problem must be solved
  • DONE: changed