gh-769: Replace celix_tss usage with libuv key

[pnoltes]

This PR replaces the custom celix_tss implementation with libuv's uv_key_t API.

Current Status

This is a draft because the libuv TLS implementation lacks a destructor callback, which was previously used to clean up celix_err_t structures. Specifically, pthread_key_create allows a destructor registration, but uv_key_create does not (likely due to limitations in the underlying Windows TLS implementation).

The Problem

Without a destructor, celix_err_t structures allocated via malloc in celix_err_getTssErr() are leaked when a thread terminates.

Proposed Paths Forward

I have identified four potential strategies to address the leak:

1. Global Registry: Store created celix_err structs in a mutex-protected list. This list is cleaned up in a __attribute__((destructor)) function.

   • Cons: Memory only gets reclaimed at program exit, not thread exit. Memory usage grows linearly with the number of unique threads that have ever reported an error.

2. Thread Monitoring: Store thread IDs in the celix_err structure and provide a periodic cleanup function that uses pthread_kill(tid, 0) to check if threads are still alive.

   • Cons: High complexity and overhead; requires the Celix framework to maintain a background cleanup cycle. Also depends on pthread api.

3. Consume-to-Cleanup + Global Registry: Free the TLS entry whenever the last error message is consumed (popped). Additionally, include Option 1 to ensure any unconsumed errors are freed at program exit.

   • Cons: This introduces frequent malloc/free calls during error-heavy operations and theoretically does not solve the growing memory issues (if users are not consuming celix_err messages).

4. Platform-Specific Hybrid + (future) Global Registry: Use libuv keys for data access but register a "shadow" pthread_key on Linux/macOS solely to trigger a destructor on thread exit (using a #ifndef _WIN32). For Windows, this would fall back to Option 1 behavior.

Current Preference: Option 3.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.40%. Comparing base (36ce8b1) to head (df80a21).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #818      +/-   ##
==========================================
+ Coverage   91.36%   91.40%   +0.03%     
==========================================
  Files         235      235              
  Lines       28686    28656      -30     
==========================================
- Hits        26209    26193      -16     
+ Misses       2477     2463      -14     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[PengZheng]

I am on vocation and will be back on the 19th. Then I will investigate on this.

[PengZheng]

I just studied the Win32 API of TLS, and found that it maps nicely to our current implementation:

Windows	POSIX
DllMain/DLL_PROCESS_ATTACH	CELIX_ERR_CONSTRUCTOR
DllMain/DLL_THREAD_DETACH	POSIX TLS destructor
DllMain/DLL_PROCESS_DETACH	CELIX_ERR_DESTRUCTOR

For Win32 support, implementing _WIN32 protected DllMain will be easy. For POSIX platforms, we just take advantage of the non-portable pthread_key_create. No need for global registry or extra thread monitoring mechanism.

WDYT? @pnoltes

Note that option 4 does not work because we cannot rely on a "shadow" pthread_key to cleanup other LTS according to man pages:

The order of destructor calls is unspecified if more than one destructor exists for a thread when it exits.

[pnoltes]

I just studied the Win32 API of TLS, and found that it maps nicely to our current implementation:

Windows POSIX
DllMain/DLL_PROCESS_ATTACH CELIX_ERR_CONSTRUCTOR
DllMain/DLL_THREAD_DETACH POSIX TLS destructor
DllMain/DLL_PROCESS_DETACH CELIX_ERR_DESTRUCTOR
For Win32 support, implementing _WIN32 protected DllMain will be easy. For POSIX platforms, we just take advantage of the non-portable pthread_key_create. No need for global registry or extra thread monitoring mechanism.

WDYT? @pnoltes

Note that option 4 does not work because we cannot rely on a "shadow" pthread_key to cleanup other LTS according to man pages:

The order of destructor calls is unspecified if more than one destructor exists for a thread when it exits.

I agree, so this means we will reject this PR. I do think it is wise to move the tss api to a separate header (instead of the threads header).

[PengZheng]

I just studied the Win32 API of TLS, and found that it maps nicely to our current implementation:
Windows POSIX
DllMain/DLL_PROCESS_ATTACH CELIX_ERR_CONSTRUCTOR
DllMain/DLL_THREAD_DETACH POSIX TLS destructor
DllMain/DLL_PROCESS_DETACH CELIX_ERR_DESTRUCTOR
For Win32 support, implementing _WIN32 protected DllMain will be easy. For POSIX platforms, we just take advantage of the non-portable pthread_key_create. No need for global registry or extra thread monitoring mechanism.
WDYT? @pnoltes
Note that option 4 does not work because we cannot rely on a "shadow" pthread_key to cleanup other LTS according to man pages:

The order of destructor calls is unspecified if more than one destructor exists for a thread when it exits.

I agree, so this means we will reject this PR. I do think it is wise to move the tss api to a separate header (instead of the threads header).

Why reject this PR?

We can still easily add Windows support to the Celix ERR just as sketched above. The only cost will be a _WIN32 protected DllMain calling uv_key_create, and an odd-looking pthread_key_create for Linux/macOS. I understand mixing pthread_key_ and uv_key_ is ugly, but it seems inevitable to support Windows.

The issue we encountered just shows that our threading API does not extend well to Windows, so replacing it is OK.
libuv API is still useful so that we can avoid as much OS-specific API as possible.

Another option is C++11 thread_local. I will give it a try.

[PengZheng]

Whoops. I messed up with commits 😢
Please have a look at 5bf532a
I think the thread_local singleton approach is nice. What do you think? @pnoltes