pnoltes commented on PR #818:
URL: https://github.com/apache/celix/pull/818#issuecomment-4069483641

   > ~Whoops. I messed up with commits 😢~ Please have a look at 
[5bf532a](https://github.com/apache/celix/commit/5bf532a41e07bde94ba9557d3d7001167e939fd4)
 I think the `thread_local` singleton approach is nice. What do you think? 
@pnoltes
   
   This change `celix_err.c` to `celix_err.cc`  so introducing a libstdc++ 
dependency. I prefer the keep the celix core binaries C and add C++ support 
using header-only implementations. 
   
   I do think the solution will work (thread_local + C++ RAII concept that free 
the allocated data on the destructor).
   
   Currently I still think this PR can be closed for now. libuv tss 
implementation currently does not offer all the features to implement celix_err 
including a good cleanup method. The API of celix_err does not leak the pthread 
tss usage, so I think this is fine. 
   
   I can make a new PR that removes the `celix_tss_*` functions from 
`celix_threads.h`. If users want a tss concept, they can use libuv or implement 
this differently. So in this case celix will not offer a user-facing tss 
abstraction api, but keep the celix_err api intact. 
   
   The focus of libuv is then more on pthread / celix_thread replacement. And 
when we want support for Windows, we use the Win32 TLS api and some`#ifdef`s. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to