core.thread: Only use pthread to store Thread.sm_this when building shared library

[dnadlinger]

This avoids calling into pthread on switching fiber contexts
with a static runtime, which can be (comparatively) very
expensive (taking a kernel spinlock).

[dnadlinger]

@liranz

[dnadlinger]

Ping @MartinNowak.

This leads to something like 30% (!) overall speedup in a fiber-heavy application.

[MartinNowak]

It would be better to address the root cause, we shouldn't signal threads that are just about to start.
I'll see if it can be done easily w/o running into issues with the messy thread startup on Windows.

[dnadlinger]

@MartinNowak: It's not like I add anything new here – the commit simply replaces version (Posix) by version (Posix && Shared). Once we have figured out the thread startup thing, we can just remove all the versioned code.

[dnadlinger]

I could also argue that this is a critical fix for a regression introduced in 399b171 (2.066). We are talking about 30% whole-application performance here, not some sort of micro-benchmark.

[MartinNowak]

Of course, all I'm saying is it looks fairly simple to do better, so I'll spend the hour trying to fix it properly.
In particularly b/c core.thread is in a horrible state w/ lots of ugly documented hacks.
For example I instantly found a bug just by thinking about this problem Issue 15268.

[MartinNowak]

See #1421 and #1422, 50% reduction of messiness in core.thread ;).
I'm actually surprised it worked out so well (b/c I tried before). But once I decided to touch everything it was a pretty straightforward change.

[dnadlinger]

Superseded by Martin's PRs.