stdlib: generalise TLS to support Windows #11949
Conversation
Rename the explicit `pthread` to `thread` to indicate that this is not `pthread` specifically. This allows us to implement the TLS support for Windows using Fibers.
| internal let _tlsKey: __swift_thread_key_t = { | ||
| let sentinelValue = __swift_thread_key_t.max | ||
| var key: __swift_thread_key_t = sentinelValue | ||
| let success = _swift_stdlib_thread_key_create(&key, _destroyTLS) |
There was a problem hiding this comment.
Is there a way to change the calling convention for _destroyTLS? On Windows (x86), this should be a __stdcall function.
There was a problem hiding this comment.
I don't think the Swift compiler can manipulate Windows calling conventions yet. It should be straightforward to rewrite _destroyTLS in C, or write a C __stdcall function that calls back into Swift.
There was a problem hiding this comment.
We could introduce a @_callingconv attribute. But, it sounds like it would be easier to move it to swift-shims and rewrite it in C.
There was a problem hiding this comment.
A shim that calls back into the stdlib for deinitialization would be my preferred approach. We have non-trivial deinitialization logic that ideally would be kept in Swift. We likewise probably want allocate/deallocate parity, and Swift knows the sizes of the TLS buffer already.
|
@swift-ci please test |
|
Given that we would previously attempt to use pthread on Windows, I think that this is better than the previous state. Ill fix the CC mismatch in a follow up (that is specific to Windows x86). |
Rename the explicit
pthreadtothreadto indicate that this is notpthreadspecifically. This allows us to implement the TLS support forWindows using Fibers.
Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.
Resolves SR-NNNN.