Richard Webb wrote:
Also, DLLs can be used in multi-threading environments.
On a related note, i'm having a bit of a problem with a D dll at the moment.
I have an Outlook COM Addin that is written in D2 using the Juno library and
that
is running ok, but i'm now trying to use a D dll from a COM addin written in C++
and i'm getting a crash inside dll_process_attach.
The only thing i get in the call stack is gcx.mark, but it appears that the
crash
is due to the GC running midway through the thread setup code. Disabling the GC
during the thread_moduleTlsCtor() calls avoids the crash, but that might just be
covering the problem up.
If there is a garbage collection going on, I assume that you do quite a
lot of initialization for TLS. Are you using callbacks into the C++ DLL
from the module ctors? This might be dangerous...
You might want to try this version of impersonate thread(), that might
work better if the C++ part also uses thread local storage:
// execute function on the TLS for the given thread
static void impersonate_thread( uint id, void function() fn )
{
if( id == GetCurrentThreadId() )
{
fn();
return;
}
// temporarily set current TLS array pointer to the array
pointer of the referenced thread
void** curteb = getTEB();
void** teb = getTEB( id );
assert( teb && curteb );
void** curtlsarray = cast(void**) curteb[11];
void** tlsarray = cast(void**) teb[11];
if( !curtlsarray || !tlsarray )
return;
curteb[11] = tlsarray;
fn();
curteb[11] = curtlsarray;
}
Especially loading more DLLs from the TLS init code will still be
troublesome...
Rainer
