fix pd_this on Windows

[Spacechild1]

On Windows it is not possible to 'properly' export a thread local variable from a DLL. MinGW can do it, but the resulting symbol (__emutls_v.pd_this) is not portable and certainly not understood by MSVC. As a consequence, Windows externals built with -DPDINSTANCE cannot really use pd_this - unless both the external and the host is built with MinGW.

The solution is to access pd_this via a function call, for this I've added a new API function pd_getinstance(). For externals, pd_this is now a macro for pd_getinstance(). Internally, we directly access 'pd_this', but we don't try to export it.

On other platforms, pd_this is now properly marked EXTERN.

[Spacechild1]

Just out of curiosity, I quickly checked on Linux: it does indeed export a symbol pd_this, but this is obviously not a pointer to the (thread-local) variable itself; rather, this is the index of the variable in the dynamic thread vector. When an external accesses pd_this, its value is automatically passed to the __tls_get_addr function, which returns the actual address of the variable for this particular thread. Now, __tls_get_addr comes from glibc and is not a standard C function. If we want our API to be a pure standard C API, we should probably apply the Windows solution to all other platforms. On the other hand, the current mechanism on Linux and macOS seems to work fine and is unlikely to change in the future (in particular, the meaning of the pd_this value).

What do you (@umlaeute, @danomatika and @millerpuckette, in particular) think about this?

(If anyone is interested in how thread-local storage actually works in Linux, I found this blog post very helpful: http://david-grs.github.io/tls_performance_overhead_cost_linux/).

[umlaeute]

looks good (after dropping the EXTERN decorator from the C-file)

[Spacechild1]

after dropping the EXTERN decorator from the C-file)

Fixed!

[danomatika]

@millerpuckette This is needed for libpd.