Difference between revisions of "Uno/Spec/Thread Affinity Bridge"
m (fixed links.) |
m |
||
| Line 1: | Line 1: | ||
| − | + | State: stable <br> | |
| − | + | Type: specification <br> | |
| − | == Thread Affinity Bridge == | + | ==Thread Affinity Bridge== |
A [[../Purpose Bridge|Purpose Bridge]] protecting [[Uno/Term/Thread Affine|Thread Affine]] objects. | A [[../Purpose Bridge|Purpose Bridge]] protecting [[Uno/Term/Thread Affine|Thread Affine]] objects. | ||
| Line 10: | Line 10: | ||
Only one thread at a time can enter a 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. | Only one thread at a time can enter a 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 === | + | ===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 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. | 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 === | + | ===API=== |
A [[../Purpose Bridge|purpose bridge]] named <code>"affine"</code>. | A [[../Purpose Bridge|purpose bridge]] named <code>"affine"</code>. | ||
| − | === Dependencies === | + | ===Dependencies=== |
* [[../Environment Stack]] | * [[../Environment Stack]] | ||
* [[../Purpose Environment]] | * [[../Purpose Environment]] | ||
Revision as of 07:11, 17 July 2006
State: stable
Type: specification
Thread Affinity Bridge
A Purpose Bridge protecting Thread Affine objects.
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 a 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".
