Initialize TSD on macOS even without Swift runtime

[copumpkin]

Without this, you get some really fun to debug segfaults at runtime because (among other things I assume) CFRunLoopGetCurrent queries TSD to avoid doing the heavier _CFRunLoopGet0 (which then sets the TSD to avoid later work). But if we don't initialize the TSD machinery, the _CFGetTSD function returns garbage and we never get a valid CFRunLoopRef.

cc @parkera @millenomi

For context, I have the standalone framework working just fine for most things, but was getting some really weird runtime crashes whenever someone used a CFRunLoop 😄

[millenomi]

I need to double-check what effect it would have on Darwin CF but it looks okay to me for now.

[millenomi]

@swift-ci please test

[copumpkin]

Yeah, agree that this might not be the correct solution, but ultimately this was my thinking:

1. TSD initialization is guarded by swift runtime
2. CFRunLoop (and others) uses TSDs regardless of swift runtime

So for it to work properly, either I think either 1 or 2 need to change or we'll get garbage TSD behavior.

[parkera]

I think this is ok. Worst case we call pthread_once more than once.

[millenomi]

Worst case, I may have a patch to conditionalize this on !DEPLOYMENT_RUNTIME_OBJC or similar.

[copumpkin]

Now that you mention it, would you expect a build with DEPLOYMENT_RUNTIME_OBJC to work for this public version? I'm intrigued 😄

Also, thanks for merging!

[millenomi]

I wouldn’t. !DEPLOYMENT_RUNTIME_OBJC (note the !) is in my limited rollout the “either Swift or standalone” flag.

[copumpkin]

Cool, I won't waste time on it then 😄I was poking at it and saw quite a bit of missing stuff (symbols that are ostensibly from Foundation that actually come from CoreFoundation, etc.) in the public release and wasn't sure if that's intentional or not, but if it is I won't waste time reporting discrepancies in it.