On 11/03/2014 03:02 PM, Shmulik Ladkani wrote:
On Mon, 03 Nov 2014 14:09:02 +0200 Taras Kondratiuk
<[email protected]> wrote:
Won't it be simpler to add a new local initialization API in your
library instead of piggy-backing on ODP local init call?
Something like:
stl_odp_local_init()
{
odp_local_init();
stl_local_init(); /* Here your lib local init is done */
}
That would be one approach, yes.
But IMO it has some disadvantages over registering a hook into
'odp_init_local':
1. Users must call 'stl_odp_local_init' upon program init (and not
odp_init_local).
And IMO that's correct, because user uses your library, but not ODP
directly. I assume the library adds some more API which will be also
called directly.
2. 'odp_init_local' is currently invoked automatically from the thread
created by 'odph_linux_pthread_create()'.
(See odp_run_start_routine, which first calls 'odp_init_local' and only
then calls the user's start_routine).
Meaning, following the 'stl_odp_local_init' paradigm, I would also
need to expose a 'stl_odph_linux_pthread_create()' that properly
invokes 'stl_odp_local_init' automatically, too.
odph_linux_pthread_create() is a helper routine, so it is not a part of
normative ODP API. You can define one for your library.
Combine these two, and let's even imagine there's more than one "entity"
that requires per-thread initialization - following the
'stl_odp_local_init' approach might get messy.
I don't have a big picture of what you are trying to achieve, but ODP
is not a framework for thread-local initialization of 3rd party
libraries. There are several ways to solve your issue without changing
ODP API:
1. Strict hierarchy - when your library is built on top of ODP and
expose its own local init function stl_odp_local_init().
2. New ODP implementation which will provide modified odp_init_local()
to initialize your library.
_______________________________________________
lng-odp mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/lng-odp
