rfc:tls

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
rfc:tls [2008/08/25 16:03] – . lbarnaudrfc:tls [2008/08/26 14:25] – . lbarnaud
Line 88: Line 88:
   * The first one will work only with position independent code, and is the faster on targets where this is the default or when comparing only to PIC builds. At least Debian builds PHP --with-pic, and I guess this is the case on other distributions too.   * The first one will work only with position independent code, and is the faster on targets where this is the default or when comparing only to PIC builds. At least Debian builds PHP --with-pic, and I guess this is the case on other distributions too.
   * The second one does not requires to build PIC code, can not fully take profit of TLS, but is the faster at least on IA-32.   * The second one does not requires to build PIC code, can not fully take profit of TLS, but is the faster at least on IA-32.
 +
 +===== Windows =====
 +
 +Dynamically loaded DLLs can use TLS starting with Windows Vista and Server 2008. But there is a restriction: TLS variables can't be exported, which means that they can't be accessed outside of the DLL. CLI and ISAPI SAPIs works with TLS enabled, but they must be built like this is done on other platforms, with all code embeded in the executable/library. The same apply for extension, they must be built statically in PHP.
  
 ===== TLS internals ===== ===== TLS internals =====
Line 103: Line 107:
 Linux, Solaris, FreeBSD, Windows. Linux, Solaris, FreeBSD, Windows.
  
-Linux, Solaris and FreeBSD implementations allocate a fixed amount of surplus memory especially to allow dynamically loaded libraries to use the static model. Linux allocates 1664 bytes, FreeBSD 64 and Solaris 512. This amount of memory is always allocated in addition of the memory allocated for TLS before program startup, and is always available (this memory can be used only by dlopen()ed modules using static TLS).+Linux, Solaris and FreeBSD implementations allocate a fixed amount of surplus memory especially to allow dynamically loaded libraries to use the static model. Linux allocates 1664 bytes, FreeBSD 64 and Solaris 512. This amount of memory is always allocated in addition of the memory allocated for TLS before program startup, and is always available (this memory can be used only by dlopen()ed modules using static TLS). These behaviors are undocumented (except by comments in Linux and FreeBSD loaders/linkers code). This has been tested with a test program and verified by reading the relevant code on Linux and FreeBSD.
  
 On GCC this model can be selected by using -ftls-model=initial-exec. On SunStudio: -xthreadvar=no%dynamic. For both, this model is the default one when building non-PIC code. On GCC this model can be selected by using -ftls-model=initial-exec. On SunStudio: -xthreadvar=no%dynamic. For both, this model is the default one when building non-PIC code.
Line 113: Line 117:
 === Implementation === === Implementation ===
  
-Linux, Solaris, FreeBSD, Windows Vista. The Windows documentation does not gives many implementation details, but it seems that Windows Vista allows DLLs to use thread local storage (not tested). Other Windows versions have no equivalent of the dynamic model.+Linux, Solaris, FreeBSD, Windows Vista/Server 2008.  
 + 
 +Windows Vista and Server 2008 can use TLS in DLLs loaded using LoadLibrary(), but TLS symbols cannot be exported, which means that only the DLL where a TLS variable is declared can refer to this variable.
  
 On GCC this model can be selected by using -ftls-model=general-dynamic. On SunStudio: -xthreadvar=dynamic. For both, this is the default when building PIC code. On GCC this model can be selected by using -ftls-model=general-dynamic. On SunStudio: -xthreadvar=dynamic. For both, this is the default when building PIC code.
rfc/tls.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1

Page Tools