Difference between revisions of "Effort/Make VCL Thread-Transparent"

Revision as of 14:42, 5 July 2006

[1], [2]

Status: in progress (UTF2)

Making VCL Thread Transparent

VCL 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:

• VCL is Thread Affine under Windows - bascially letting shine through the Win32 thread affinity regarding window messages, window construction and window destruction.
• VCL provides the Solar MutEx, which needs to be acquired befor VCL can be called.
• VCL completely releases the Solar MutEx in some sitations, 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

• remove the Solar MutEx completely and to declare VCL to be Thread Unsafe, therefor going to run in the "c++:unsafe" UNO Purpose Environment, and to
• encapsulate calls to the Thread Affine Win32 API, in a way, that this thread affinity is not visible from the outside (Thread Transparency). The goal being that VCL behaves as an ordinary library, not showing any threading behavior at all.

Support short MutEx Acquiration Times

To ensure short MutEx acquiration 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 interims 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 asynchron and deprecating / removing the execute method.

Time Frame

At least Removing the Solar MutEx and Encapsulating the inherited Win32 Thread Affinity are going to depend on Uno/Effort/Creating the Uno Threading Framework, therefor VCL Thread Transparency will earliest be available after the UTF.

Tasks

Title	State
Make Dialogs Asynchronous	in progress
Effort/Encapsulate the Win32 thread affinity	UTF2
Fix DDE to not rely on main thread	UTF2
Remove the Solar MutEx and adapt the KDE/GTK backends	proof
Create a Handle API or Interims Solution	open