Are you doing ODP C++ class and need proper destroy functions on this
class delete?
odph_linux_pthread_create() and other odph_ are helper functions. You
can use them, but it's not part of
ODP API. So fill free to call odp API directly (i.e. do the same but add
your stl thing there).
BR,
Maxim.
On 11/03/2014 03:09 PM, Taras Kondratiuk wrote:
On 11/03/2014 12:22 PM, Shmulik Ladkani wrote:
Hi Taras,
On Mon, 03 Nov 2014 12:00:33 +0200 Taras Kondratiuk
<taras.kondrat...@linaro.org> wrote:
Could you please elaborate it? What is a usecase?
Think of a library extending the ODP library.
Specifically, I was playing around creating a C++ STL compatible
allocator template, whose implementation is based on ODP building
blocks.
(Well, I assume that most ODP apps would be written in C, and even if
written in C++, they'd probably use ODP memory allocation interfaces
directly for their specific needs. However such a library *could* allow
one to use STL data structures allocated by ODP means).
Such a library is unaware of how many threads its user will create, but
it needs to initialize some per-thread locals it has.
An 'odp_init_local_register' interface would allow one to do so, and
it's pretty harmful as it exposes none of ODP's internals.
The registered function may use any standard interfaces the ODP allows.
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 */
}
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp
