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

From Apache OpenOffice Wiki
Jump to: navigation, search
m (Added some links.)
(Improved structure, added links.)
Line 5: Line 5:
 
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 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:
+
; VCL hampers thread transparency in the following ways:
−
* It is [[Uno/Spec/Thread Affine | Thread Affine]] under Windows - bascially letting shine through the Win32 thread affinity regarding window messages, window construction and window destruction.
+
:* It is [[Uno/Spec/Thread Affine | 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 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.
+
:* 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 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.
 
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.
  
−
To make VCL thread transparent, we propose, to
+
; To make VCL thread transparent, we propose, to:
−
* remove the Solar MutEx completely and declare VCL to be non-thread-safe, and to  
+
:* remove the Solar MutEx completely and declare VCL to be [[Uno/Spec/Thread Unsafe | Thread Unsafe]], and to  
−
* encapsulate calls to the [[Uno/Spec/Thread Affine | Thread Affine]] Win32 API, in a way, that this thread affinity is not visible from the outside.
+
:* encapsulate calls to the [[Uno/Spec/Thread Affine | 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.
 
The goal being that VCL behaves as an ordinary library, not showing any threading behavior at all.
  
Line 20: Line 20:
 
* add a system handle providing API, so that we can poll/select on the handle in an outer event loop, and only need to enter VCL in case of an event.
 
* add a system handle providing API, so that we can poll/select on the handle in an outer event loop, and only need to enter VCL in case of an event.
  
−
Side effects:
+
; 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.
+
:* 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 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 acuired, basically disallowing other threads to enter VCL. This is needs to be addressed by [[Async Dialogs | making the office dialogs asynchron]].
+
:* 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 acuired, basically disallowing other threads to enter VCL. This is needs to be addressed by [[Async Dialogs | making the office dialogs asynchron]].
  
 +
; 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.
  
−
{| style="vertical-align:top; text-align:left; background-color:#F0F0F0;"
+
; Dependencies:
−
|+ style="font-weight:bold; color:#FFFFFF; background-color:#00315A;" | Tasks for VCL Thread Transparency
+
{|border="1" cellspacing="0" class="wikitable"
−
|- style="background-color:#99CCFF; font-weight:bold;"
+
|- style="background:#efefef;"  
−
| Title || Spec || % || Changed || Impl || % || Changed || Test || % || Changed
+
| Task || State
 
|-
 
|-
−
| API providing a system handle to pollable for messages || 0.0 || 0% || 12/14/2005 || proof || 0% || 12/14/2005
+
| [[Async Dialogs | Make Dialogs Asynchronous]] || 90%
 
|-
 
|-
−
| Remove the SolarMutex || 0.0 || 0% || 12/14/2005 || proof || 0% || 12/14/2005
+
| [[Creating a Handle API]] || 90%
 
|-
 
|-
−
| Encapsulate Win32 thread affinity || 0.0 || 0% || 12/14/2005 || proof || 0% || 12/14/2005
+
| [[Removing the Solar MutEx]] || 0%
−
|-
+
−
| 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
+
| [[Encapsulating the inherited Win32 Thread Affinity]] || 90%
 +
|-
 +
| [[Fix DDE support to not rely on main thread]] || 0%
 
|}
 
|}
  
−
The above tasks are going to depend on the Extended UNO Threading Framework, therefor VCL Thread Transparency will earliest be available after the UTF.
 
  
 
[[Category:Effort]]
 
[[Category:Effort]]

Revision as of 14:22, 21 April 2006

[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 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.

To make VCL thread transparent, we propose, to
  • remove the Solar MutEx completely and declare VCL to be Thread Unsafe, 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 MutEx acquiration times, we propose to

  • add a system handle providing API, so that we can poll/select on the handle in an outer event loop, 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 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 acuired, basically disallowing other threads to enter VCL. This is needs to be addressed by making the office dialogs asynchron.
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.
Dependencies
Task State
Make Dialogs Asynchronous 90%
Creating a Handle API 90%
Removing the Solar MutEx 0%
Encapsulating the inherited Win32 Thread Affinity 90%
Fix DDE support to not rely on main thread 0%
Retrieved from "https://wiki.openoffice.org/w/index.php?title=Effort/Make_VCL_Thread-Transparent&oldid=8903"
Personal tools