Effort/Make VCL Thread-Transparent

From Apache OpenOffice Wiki
< Effort
Revision as of 07:12, 19 June 2007 by Kr (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Type: Effort State: 85% Owner: Kay Ramme

VCL (Visual Components Library) provides the OOo base widget set and windowing abstraction. It manages the event loop and dispatches the events. It also owns the display connection and manages various resources, e.g. fonts.

The goal of this effort is, to make VCL thread-transparent.

Problem

VCL hampers Thread-Transparency

VCL hampers thread-transparency in the following ways:

  • On Win32:
    • VCL is thread-affine under Windows - basically letting shine through the Win32 thread-affinity regarding window messages, window construction and window destruction.
    • VCL provides access to the main-thread, which basically is the thread which initializes VCL and which is expected to eventually enter the event-loop, on Win32.
    • VCL initializes the initiating threads apartment as STA on Win32. See gsl/vcl/source/app/svmain.cxx
  • VCL provides the Solar Mutex, which needs to be acquired before VCL can be called.
  • VCL completely releases the Solar Mutex in some situations, without any hints at the API.

VCLs internals are not protected against concurrent access, except by the Solar Mutex, which needs to be locked from the outside. VCLs API only provides blocking or polling functions for accessing the event loop, which is especially bad as it does not offer a way, to avoid long acquired MutExes, while waiting for events, except by actively polling.

Solution

Make VCL Thread-Transparent

To make VCL thread-transparent, we plan to

Support short MutEx Acquisition Times

To ensure short MutEx acquisition times, we plan to

  • add a system handle providing API, so that we can poll/select on the handle in an outer loop, and only need to enter VCL in case of pending events. Unfortunately, this seems to depend on the removal of the internal VCL event loop, so we may go with an interim solution.

Fix Side Effects

  • Some Win32 based OOo components (e.g. DDE) rely on their initializing thread to eventually enter the VCL event loop, to dispatch messages for objects created during this initialization. These implementations need to be adapted, to either delegate Win32 thread-affine calls into VCLs new internal thread, or to create a thread for dispatching purposes by their own.
  • With the removal of the Solar Mutex, VCL can not release a protecting MutEx anymore, which it currently does when executing a dialog. That means, that a protecting MutEx will stay acquired during presence of the dialog, basically disallowing other threads to enter VCL. This is going to be be addressed by making the office dialogs asynchronous and deprecating / removing the execute method.

Time Frame

At least the Effort/Encapsulate the Win32 thread affinity depends on Uno/Effort/Binary/Extend Threading-Model, therefor VCL thread-transparency will earliest be available after the bunoexttm CWS.

Tasks&CWS

Title State CWS Dependencies
Effort/Make Dialogs Asynchronous 75% asyncdialogs asyncdialogs2
Move Solar Mutex implementations (SalYieldMutex) into platform independent part. 0% vclYieldmutexReduction
Win32: Remove unnecessary "SendMessage" indirections in VCL backend. 0% vclYieldmutexReduction
Avoid releasing the Solar Mutex while being Application::Execute / Dialog::Execute 75% vclThreadTransparency asyncdialogs2
Win32: Encapsulate thread-affinity. 75% vclThreadTransparency bunoexttm
Fix "main-thread" API usages. These are thread-affinity workarounds only. open vclThreadTransparency
Win32: Fix (potential) implicit "GetMessage" dependencies. open vclThreadTransparency bunoexttm
Remove "main-thread-executor". open vclThreadTransparency
Remove "main-thread" access API (vcl/inc/svapp.hxx). open vclThreadTransparency
Create handle API. 75% vclThreadTransparency bunoexttm
Deprecate Application::Execute and Dialog::Execute. 75% vclThreadTransparency
Adapt soffice event-loop (desktop/source/app) to the handle API. 75% vclThreadTransparency
Win32: Simplify Drag&Drop and Clipboard by using Binary Unos extended threading model open vclSingleDispatch vclThreadTransparency
Remove Solar Mutex usages. open vclRetireSolarMutex vclThreadTransparency NewThreadingArch
Remove Solar Mutex (AKA YieldMutex) API and implementation. open vclRetireSolarMutex
Personal tools