[olofsonprojects] Re: Portable thread local storage?
- From: Damyan Ivanov <dmn@xxxxxxxxxx>
- To: olofsonprojects@xxxxxxxxxxxxx
- Date: Sat, 28 Nov 2009 15:03:22 +0200
-=| David Olofson, Sat, Nov 28, 2009 at 02:37:08AM +0100 |=-
>
> I'm working on an audio processing framework [*] with an API in the
> style of OpenGL and OpenAL. For various reasons (probably similar to
> those that led the OpenGL and OpenAL designers to the same
> decision), I'm using integer names, as opposed to pointers, to
> reference objects.
I wonder what these reasons are. Using pointers leads straight to 3.
below, without any overhead I can see. You have to dereference object
names anyway - look them up in an array (i.e. dereferencing another
pointer).
And I thing passing around a pointer would have same properties
performance-wise as an integer.
> 1. Add an a2_MakeCurrent() call, to select the target context
> for subsequent context related API calls. Integer names are
> context local, and there are no context names or pointers
> being passed to any normal API calls.
As you point below, this is really ugly for multi-threading.
Thread-local storage brings some performance penalties, I've heard.
> 2. Encode the parent context of objects in the integer names.
> (This is sort of like passing a context pointer around, but
> you hide this by extracting the context out of other object
> references that you'll need to use with any API "command"
> call anyway.)
If pointers are used, each object can naturaly hold a reference to its
context.
> 3. The standard "OOP" style solution: Explicitly pass a context
> pointer to any API function that deals with a context.
Maybe you can keep the parents in a global array indexed by object
name? It would imply that objects are named from 0 on though and
perhaps will need keeping a bitmap of used/free indices.
Sorry if my ideas are too naive :) I hope that they would at least
point you to some new approaches.
--
dam
Other related posts:
