Hi, > 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.
I completely agree. However my usecase is an exception, as I was trying to create a C++ binding for ODP - hence it isn't just a "different" library which uses ODP, but rather "wraps" ODP. In that sense, if for example the C++ binding was decided to be integral part of ODP, than 'odp_init_local' would simply call 'stl_init_local' *directly*. Anyway, I would be glad to elaborate on the motivation in today's call. > odph_linux_pthread_create() is a helper routine, so it is not a part of > normative ODP API. OK. So may I suggest the following. Currently, 'odph_linux_pthread_create' helper *implicitly* calls 'odp_init_local' upon thread start, prior invoking user's start_routine. Obviously, this removes user's burden of calling 'odp_init_local' directly early on her start_routine - at least for users using odph_linux_pthread_create. However, *if* a different platform implemenets its own helper (yes, not a part of formal ODP API), it might/might-not follow the same "automatic convenience" - depending on platform implementor's will/preference. Thus, the user (which writes platform agnostic code) implementing a thread routine needs to be aware of what the helper does (does it automatically call odp_init_local? or, need I call it on my own?). Therefore, I suggest removing the implicit call to 'odp_init_local' from the existing odph_linux_pthread_create helper - forcing the user to *always* call 'odp_init_local' early in her thread routine - similarly to what she does early on 'main()'. Regards, Shmulik _______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
