Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>Здравствуйте, Tom, Вы писали:
E>>>>Т.о. в языке D сделан еще один шаг к тому, чтобы сделать язык максимально multi-thread/multi-core friendly.
DEA>>>Не знаю как на юнихе, а на винде, статически обьявленные TLS-переменные не работают в .DLL-ях.
Tom>>Это как?
DEA>А вот так. По умолчанию все не-автоматические переменные превращаются... превращаются переменные... в thread-local.
DEA>А чтобы глобальная переменная стала действительно глобальной, ей надо будет сказать "shared".
Tom>>И вообще причём тут DLL и TLS?
DEA>Вот при этом (курим "Rules and Limitations for TLS" в MSDN):
DEA>DEA>If a DLL declares any nonlocal data or object as __declspec( thread ), it can cause a protection fault if dynamically loaded. After the DLL is loaded with LoadLibrary, it causes system failure whenever the code references the nonlocal __declspec( thread ) data. Because the global variable space for a thread is allocated at run time, the size of this space is based on a calculation of the requirements of the application plus the requirements of all the DLLs that are statically linked. When you use LoadLibrary, there is no way to extend this space to allow for the thread local variables declared with __declspec( thread ). Use the TLS APIs, such as TlsAlloc, in your DLL to allocate TLS if the DLL might be loaded with LoadLibrary.
DEA>...как следствие, динамически подгружаемые DLL-и на D писать станет ну оооочень трудно.
В своё время два дня на это убил
__declspec( thread ) действительно не работает в дллках, загруженных через LoadLibrary (впрочем, в Висте уже работает). Зато обычный АПИ прекрасно справляется (ТлсАллок и пр).
