Effort/Make VCL Thread-Transparent

[1], [2]

Status: in progress

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.

VCL hampers thread transparency in the following ways:

• It is thread affine under Windows - bascially letting shine through the Win32 thread affinity regarding window messages, window construction and window destruction.
• It provides the solar mutex, which needs to be acquired befor VCL can be called.
• It 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 SolarMutex, 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 polling.

To make VCL thread transparent, we propose, to

• remove the SolarMutex completely and declare VCL to be non-thread-safe, and to
• encapsulate calls to the thread affine Win32 API, in a way, that this thread affinity is not visible from the outside.

The goal being that VCL behaves as an ordinary library, not showing any threading behavior at all.

To ensure short MutexEx acquiration times, we propose to

• add a system handle providing API, so that we can poll/select the handle and only need to enter VCL in case of an event.

Side effects:

• Some Win32 based OOo components (DDE) expect their initialising thread eventually to 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 SolarMutex, VCL can not release a protecting MutEx anymore, which it currently does when executing a dialog. That means, that a protecting MutEx will stay acuired, basically disallowing other threads to enter VCL.

Tasks for VCL Thread Transparency

Title	Spec	%	Changed	Impl	%	Changed	Test	%	Changed
API providing a system handle to pollable for messages	0.0	0%	12/14/2005	proof	0%	12/14/2005
Remove the SolarMutex	0.0	0%	12/14/2005	proof	0%	12/14/2005
Encapsulate Win32 thread affinity	0.0	0%	12/14/2005	proof	0%	12/14/2005
Adapt DDE to use same thread for initialisation as VCL is going to use for internal purposes	0.0	0%	04/05/2006	open	0%	04/05/2006	0%	04/05/2006
Rework OOo code, where dialogs get executed and concurrent threads need to enter VCL	0.0	0%	04/05/2006	proof	0%	04/05/2006	0%	04/05/2006

The above tasks are going to depend on the Extended UNO Threading Framework, therefor VCL Thread Transparency will earliest be available after the UTF.