среда, 16 мая 2012 г.


I already claimed that ecl.dll crashes when loaded from .dll in ecl.dll!_GC_init_thread_local(). So finally I know why. Short answer - bcs it contains static TLS and so cannot be loaded with LoadLibrary:
On Windows operating systems before Windows Vista, __declspec( thread ) has some limitations. If a DLL declares any 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 __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, you cannot extend this space to allow for the thread local variables declared with __declspec( thread )
Problem is that thread_local_alloc.c (where located function GC_init_thread_local) MUST be used bcs it required for elc threads. And you just cannot build ECL without threads support - msvc\Makefile contains following astounding lines:
# Currently it is NOT SUPPORTED to build ECL without threads. The reason
# is that certain exception handlers in Windows always use new threads.

Комментариев нет:

Отправить комментарий