Difference between revisions of "Uno/Spec/Thread Affinity Bridge"
m (→API: Fixed "purpose" name.) |
|||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | Type: specification State: stable | |
| − | Type: | + | |
| − | + | A [[../Purpose Bridge|purpose bridge]] protecting [[Uno/Term/Thread Affine|thread-affine]] objects. | |
| − | A [[../Purpose Bridge| | + | |
| − | + | ==Feature== | |
| − | The Thread | + | The [[Uno/Term/Thread Affine|thread-affinity]] bridge ensures that encapsulated objects are always called by the same thread, thus compensating any [[Uno/Term/Thread Affine|thread-affinity]]. The affinity bridge also ensures, that calls into or through it do not show any [[Uno/Term/Thread Aware|thread awareness]]. |
| − | Only one thread at a time can enter | + | Only one thread at a time can enter an affinity environment, an affinity environment is entered, if any thread has one of the methods provided by the <code>Enterable</code> API on the stack. |
| − | + | ==Rationale== | |
| − | Some APIs have [[Uno/Term/Thread Affine|thread affinities]] in respect to particular handles they return. For example, on Win32 the window-destroy and -message functions require to be called by the same thread which actually created the window. This thread affinity is inherited when developing APIs on top of these thread affine APIs | + | Some APIs have [[Uno/Term/Thread Affine|thread-affinities]] in respect to particular handles they return. For example, on Win32 the window-destroy and -message functions require to be called by the same thread which actually created the window. This [[Uno/Term/Thread Affine|thread-affinity]] is inherited when developing APIs on top of these [[Uno/Term/Thread Affine|thread-affine]] APIs. |
| − | + | ||
| − | + | In general, [[Uno/Term/Thread Affine|thread-affine]] APIs are hard to program, especially in generic frameworks where it is not knowable before hand how long a thread lives and on whichs objects it calls. | |
| + | |||
| + | ==API== | ||
A [[../Purpose Bridge|purpose bridge]] named <code>":affine"</code>. | A [[../Purpose Bridge|purpose bridge]] named <code>":affine"</code>. | ||
| − | + | ==Dependencies== | |
* [[../Environment Stack]] | * [[../Environment Stack]] | ||
* [[../Purpose Environment]] | * [[../Purpose Environment]] | ||
| + | [[Category:Draft]] | ||
| + | [[Category:Spec]] | ||
| + | [[Category:Uno]] | ||
[[Category:Uno:Spec]] | [[Category:Uno:Spec]] | ||
| + | [[Category:Multi-Threading]] | ||
Latest revision as of 07:21, 19 June 2007
Type: specification State: stable
A purpose bridge protecting thread-affine objects.
Contents
Feature
The thread-affinity bridge ensures that encapsulated objects are always called by the same thread, thus compensating any thread-affinity. The affinity bridge also ensures, that calls into or through it do not show any thread awareness.
Only one thread at a time can enter an affinity environment, an affinity environment is entered, if any thread has one of the methods provided by the Enterable API on the stack.
Rationale
Some APIs have thread-affinities in respect to particular handles they return. For example, on Win32 the window-destroy and -message functions require to be called by the same thread which actually created the window. This thread-affinity is inherited when developing APIs on top of these thread-affine APIs.
In general, thread-affine APIs are hard to program, especially in generic frameworks where it is not knowable before hand how long a thread lives and on whichs objects it calls.
API
A purpose bridge named ":affine".
