pnoltes opened a new pull request, #818:
URL: https://github.com/apache/celix/pull/818
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.
--
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]
