is DbgEng actually thread-safe ?

Daniel_Terhell · September 25, 2012, 4:15am

When I call my dump analysis code from multiple threads, any call to the
debug engine can fail with E_UNEXPECTED Catastrophic failure. For instance:
:
IDebugControl::GetNumberProcessors
IDebugControl::GetPageSize
IDebugControl::GetStackTrace

If all calls are made from the same thread, there is never an error
returned.

I have made sure all there are no resources shared between the threads
whatsoever and that all my own code is thread safe. If I serialize the
entire routine that uses DbgEng with a critical section, so no multiple
threads are using the engine at the same time, the problem remains.

Is there some magic switch somewhere to put the engine into thread-safe mode
? Or is it not supported ? If it is not supported, can I safely assume that
I can at least start one thread that uses dbgeng per process ?

//Daniel

OSR_Community_User · September 25, 2012, 12:17pm

No, DbgEng is NOT thread safe.

You will need to synchronize yourself before calling into it.

Joe.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@resplendence.com
Sent: Tuesday, September 25, 2012 1:15 AM
To: Kernel Debugging Interest List
Subject: [windbg] is DbgEng actually thread-safe ?

When I call my dump analysis code from multiple threads, any call to the debug engine can fail with E_UNEXPECTED Catastrophic failure. For instance:
:
IDebugControl::GetNumberProcessors
IDebugControl::GetPageSize
IDebugControl::GetStackTrace

If all calls are made from the same thread, there is never an error returned.

I have made sure all there are no resources shared between the threads whatsoever and that all my own code is thread safe. If I serialize the entire routine that uses DbgEng with a critical section, so no multiple threads are using the engine at the same time, the problem remains.

Is there some magic switch somewhere to put the engine into thread-safe mode ? Or is it not supported ? If it is not supported, can I safely assume that I can at least start one thread that uses dbgeng per process ?

//Daniel

WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Daniel_Terhell · September 25, 2012, 12:29pm

Thanks for your answer. As it shows, even serialzing the jobs will not help
avoiding the problems. As it appears to me, there can be only one thread in
a process that makes calls to the engine. Multiple threads are not
supported, even if only one of them does a DBGENG job at a time.

Another question, is DBGENG using any global or kernel resources that would
make it not thread-safe even between different processes ? Because every
process instance gets a fresh copy of DBGENG.DLL, can I spawn as many
processes as I desire and still achieve multithreading through multiple
processes ?

//Daniel

“Joe Ballantyne” wrote in message
news:xxxxx@windbg…
No, DbgEng is NOT thread safe.

You will need to synchronize yourself before calling into it.

Joe.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@resplendence.com
Sent: Tuesday, September 25, 2012 1:15 AM
To: Kernel Debugging Interest List
Subject: [windbg] is DbgEng actually thread-safe ?

When I call my dump analysis code from multiple threads, any call to the
debug engine can fail with E_UNEXPECTED Catastrophic failure. For instance:
:
IDebugControl::GetNumberProcessors
IDebugControl::GetPageSize
IDebugControl::GetStackTrace

If all calls are made from the same thread, there is never an error
returned.

I have made sure all there are no resources shared between the threads
whatsoever and that all my own code is thread safe. If I serialize the
entire routine that uses DbgEng with a critical section, so no multiple
threads are using the engine at the same time, the problem remains.

Is there some magic switch somewhere to put the engine into thread-safe mode
? Or is it not supported ? If it is not supported, can I safely assume that
I can at least start one thread that uses dbgeng per process ?

//Daniel

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Jen-Lung_Chiu-2 · September 25, 2012, 12:32pm

DBGENG API IS THREAD SAFE.

One question, how did you share the IDebugControl “interface” pointer among the threads?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@resplendence.com
Sent: Tuesday, September 25, 2012 09:28 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] is DbgEng actually thread-safe ?

Thanks for your answer. As it shows, even serialzing the jobs will not help avoiding the problems. As it appears to me, there can be only one thread in a process that makes calls to the engine. Multiple threads are not supported, even if only one of them does a DBGENG job at a time.

Another question, is DBGENG using any global or kernel resources that would make it not thread-safe even between different processes ? Because every process instance gets a fresh copy of DBGENG.DLL, can I spawn as many processes as I desire and still achieve multithreading through multiple processes ?

//Daniel

“Joe Ballantyne” wrote in message news:xxxxx@windbg…
No, DbgEng is NOT thread safe.

You will need to synchronize yourself before calling into it.

Joe.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@resplendence.com
Sent: Tuesday, September 25, 2012 1:15 AM
To: Kernel Debugging Interest List
Subject: [windbg] is DbgEng actually thread-safe ?

When I call my dump analysis code from multiple threads, any call to the debug engine can fail with E_UNEXPECTED Catastrophic failure. For instance:
:
IDebugControl::GetNumberProcessors
IDebugControl::GetPageSize
IDebugControl::GetStackTrace

If all calls are made from the same thread, there is never an error returned.

I have made sure all there are no resources shared between the threads whatsoever and that all my own code is thread safe. If I serialize the entire routine that uses DbgEng with a critical section, so no multiple threads are using the engine at the same time, the problem remains.

Is there some magic switch somewhere to put the engine into thread-safe mode ? Or is it not supported ? If it is not supported, can I safely assume that I can at least start one thread that uses dbgeng per process ?

//Daniel

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Ladislav_Zezula · September 25, 2012, 12:37pm

> As it appears to me, there can be only one thread in

a process that makes calls to the engine.

This is not true. WinDbg has multiple threads, and they all make calls
to the engine. However, Windbg creates a new IDebugClient for each
thread, and each thread uses its own created copy of IDebugClient.

As far as I understand, all instances of IDebugClient use common
debug session, so using any of them yields the same results.

L.

Daniel_Terhell · September 25, 2012, 12:42pm

There is a separate local different object pointer (and everything) for each
thread. I was assuming the threading model was inherited from COM call
through the CoInitialieEx calls and the parameter passed to it.

But Joe says it’s NOT thread-safe. Or should I be sharing one of the
interface pointers between the threads to make it work ?

//Daniel

“Jen-Lung Chiu” wrote in message
news:xxxxx@windbg…
DBGENG API IS THREAD SAFE.

One question, how did you share the IDebugControl “interface” pointer among
the threads?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@resplendence.com
Sent: Tuesday, September 25, 2012 09:28 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] is DbgEng actually thread-safe ?

Thanks for your answer. As it shows, even serialzing the jobs will not help
avoiding the problems. As it appears to me, there can be only one thread in
a process that makes calls to the engine. Multiple threads are not
supported, even if only one of them does a DBGENG job at a time.

Another question, is DBGENG using any global or kernel resources that would
make it not thread-safe even between different processes ? Because every
process instance gets a fresh copy of DBGENG.DLL, can I spawn as many
processes as I desire and still achieve multithreading through multiple
processes ?

//Daniel

“Joe Ballantyne” wrote in message
news:xxxxx@windbg…
No, DbgEng is NOT thread safe.

You will need to synchronize yourself before calling into it.

Joe.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@resplendence.com
Sent: Tuesday, September 25, 2012 1:15 AM
To: Kernel Debugging Interest List
Subject: [windbg] is DbgEng actually thread-safe ?

When I call my dump analysis code from multiple threads, any call to the
debug engine can fail with E_UNEXPECTED Catastrophic failure. For instance:
:
IDebugControl::GetNumberProcessors
IDebugControl::GetPageSize
IDebugControl::GetStackTrace

If all calls are made from the same thread, there is never an error
returned.

I have made sure all there are no resources shared between the threads
whatsoever and that all my own code is thread safe. If I serialize the
entire routine that uses DbgEng with a critical section, so no multiple
threads are using the engine at the same time, the problem remains.

Is there some magic switch somewhere to put the engine into thread-safe mode
? Or is it not supported ? If it is not supported, can I safely assume that
I can at least start one thread that uses dbgeng per process ?

//Daniel

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Jen-Lung_Chiu-2 · September 25, 2012, 12:46pm

DBGENG is thread safe as conceptually itself will serialize all calls (using own global critical section). You could call DBGENG APIs from multiple threads as this is how WINDBG does.

As earlier post suggested, you could try call DebugCreate() then QI for different IDebugxxx interfaces from every thread.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@resplendence.com
Sent: Tuesday, September 25, 2012 09:41 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Re:is DbgEng actually thread-safe ?

There is a separate local different object pointer (and everything) for each thread. I was assuming the threading model was inherited from COM call through the CoInitialieEx calls and the parameter passed to it.

But Joe says it’s NOT thread-safe. Or should I be sharing one of the interface pointers between the threads to make it work ?

//Daniel

“Jen-Lung Chiu” wrote in message news:xxxxx@windbg…
DBGENG API IS THREAD SAFE.

One question, how did you share the IDebugControl “interface” pointer among the threads?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@resplendence.com
Sent: Tuesday, September 25, 2012 09:28 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] is DbgEng actually thread-safe ?

Thanks for your answer. As it shows, even serialzing the jobs will not help avoiding the problems. As it appears to me, there can be only one thread in a process that makes calls to the engine. Multiple threads are not supported, even if only one of them does a DBGENG job at a time.

Another question, is DBGENG using any global or kernel resources that would make it not thread-safe even between different processes ? Because every process instance gets a fresh copy of DBGENG.DLL, can I spawn as many processes as I desire and still achieve multithreading through multiple processes ?

//Daniel

“Joe Ballantyne” wrote in message news:xxxxx@windbg…
No, DbgEng is NOT thread safe.

You will need to synchronize yourself before calling into it.

Joe.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@resplendence.com
Sent: Tuesday, September 25, 2012 1:15 AM
To: Kernel Debugging Interest List
Subject: [windbg] is DbgEng actually thread-safe ?

When I call my dump analysis code from multiple threads, any call to the debug engine can fail with E_UNEXPECTED Catastrophic failure. For instance:
:
IDebugControl::GetNumberProcessors
IDebugControl::GetPageSize
IDebugControl::GetStackTrace

If all calls are made from the same thread, there is never an error returned.

I have made sure all there are no resources shared between the threads whatsoever and that all my own code is thread safe. If I serialize the entire routine that uses DbgEng with a critical section, so no multiple threads are using the engine at the same time, the problem remains.

Is there some magic switch somewhere to put the engine into thread-safe mode ? Or is it not supported ? If it is not supported, can I safely assume that I can at least start one thread that uses dbgeng per process ?

//Daniel

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Ladislav_Zezula · September 25, 2012, 12:56pm

> As earlier post suggested, you could try call DebugCreate() then QI

for different IDebugxxx interfaces from every thread.

You can also call IDebugClient::CreateClient, which is what WinDbg does.

OSR_Community_User · September 25, 2012, 3:55pm

I;m just guessing here, but you are showing what appears to be a COM
interface, which implies UMDF. COM has “threading models” which allow for
either single-thread-only or multiple-thread usage. If it was built for
single-thread (“apartment model”), then it will not only be
non-thread-safe, it is undefined what happens if it is called from
multiple threads, but you can generally assume the worst. Note that it is
not guaranteed that even if you do external synchronization that you can
safely call it from multiple threads; the traditional way this is handled
is to have one thread “own” it, and other threads send messages to this
thread to perform actions on the object. Since you do not have the
sources to the object, you cannot change how it was designed to work.
joe

When I call my dump analysis code from multiple threads, any call to the
debug engine can fail with E_UNEXPECTED Catastrophic failure. For
instance:
:
IDebugControl::GetNumberProcessors
IDebugControl::GetPageSize
IDebugControl::GetStackTrace

If all calls are made from the same thread, there is never an error
returned.

I have made sure all there are no resources shared between the threads
whatsoever and that all my own code is thread safe. If I serialize the
entire routine that uses DbgEng with a critical section, so no multiple
threads are using the engine at the same time, the problem remains.

Is there some magic switch somewhere to put the engine into thread-safe
mode
? Or is it not supported ? If it is not supported, can I safely assume
that
I can at least start one thread that uses dbgeng per process ?

//Daniel

WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Doron_Holan · September 25, 2012, 4:01pm

The interface to dbgeng is com interfaces. While umdf also uses com, the only thing they have in common is the com interface abstraction. Umdf does not apply here

d

debt from my phone

From: xxxxx@flounder.com
Sent: 9/25/2012 12:55 PM
To: Kernel Debugging Interest List
Subject: Re: [windbg] is DbgEng actually thread-safe ?

I;m just guessing here, but you are showing what appears to be a COM
interface, which implies UMDF. COM has “threading models” which allow for
either single-thread-only or multiple-thread usage. If it was built for
single-thread (“apartment model”), then it will not only be
non-thread-safe, it is undefined what happens if it is called from
multiple threads, but you can generally assume the worst. Note that it is
not guaranteed that even if you do external synchronization that you can
safely call it from multiple threads; the traditional way this is handled
is to have one thread “own” it, and other threads send messages to this
thread to perform actions on the object. Since you do not have the
sources to the object, you cannot change how it was designed to work.
joe

When I call my dump analysis code from multiple threads, any call to the
debug engine can fail with E_UNEXPECTED Catastrophic failure. For
instance:
:
IDebugControl::GetNumberProcessors
IDebugControl::GetPageSize
IDebugControl::GetStackTrace

If all calls are made from the same thread, there is never an error
returned.

I have made sure all there are no resources shared between the threads
whatsoever and that all my own code is thread safe. If I serialize the
entire routine that uses DbgEng with a critical section, so no multiple
threads are using the engine at the same time, the problem remains.

Is there some magic switch somewhere to put the engine into thread-safe
mode
? Or is it not supported ? If it is not supported, can I safely assume
that
I can at least start one thread that uses dbgeng per process ?

//Daniel

WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Daniel_Terhell · September 26, 2012, 2:31am

wrote in message news:xxxxx@windbg…
>> As earlier post suggested, you could try call DebugCreate() then QI
>> for different IDebugxxx interfaces from every thread.
>
> You can also call IDebugClient::CreateClient, which is what WinDbg does.

Thanks CreateClient did the trick. Though I still need to add my own
serialization to make it work.

Either way, this work is serialized so there is little point in having
multiple threads for performance. Assuming every process has a separate copy
of the engine (and doesn’t need exclusive access to any system wide
resource), I’m going to look into running multiple processes that can
execute the jobs concurrently.

//Daniel

OSR_Community_User · September 26, 2012, 2:17pm

OK, but the threading model issues are the same no matter what.
joe

The interface to dbgeng is com interfaces. While umdf also uses com, the
only thing they have in common is the com interface abstraction. Umdf does
not apply here

d

debt from my phone

From: xxxxx@flounder.com
Sent: 9/25/2012 12:55 PM
To: Kernel Debugging Interest List
Subject: Re: [windbg] is DbgEng actually thread-safe ?

I;m just guessing here, but you are showing what appears to be a COM
interface, which implies UMDF. COM has “threading models” which allow for
either single-thread-only or multiple-thread usage. If it was built for
single-thread (“apartment model”), then it will not only be
non-thread-safe, it is undefined what happens if it is called from
multiple threads, but you can generally assume the worst. Note that it is
not guaranteed that even if you do external synchronization that you can
safely call it from multiple threads; the traditional way this is handled
is to have one thread “own” it, and other threads send messages to this
thread to perform actions on the object. Since you do not have the
sources to the object, you cannot change how it was designed to work.
joe

> When I call my dump analysis code from multiple threads, any call to the
> debug engine can fail with E_UNEXPECTED Catastrophic failure. For
> instance:
> :
> IDebugControl::GetNumberProcessors
> IDebugControl::GetPageSize
> IDebugControl::GetStackTrace
>
> If all calls are made from the same thread, there is never an error
> returned.
>
> I have made sure all there are no resources shared between the threads
> whatsoever and that all my own code is thread safe. If I serialize the
> entire routine that uses DbgEng with a critical section, so no multiple
> threads are using the engine at the same time, the problem remains.
>
> Is there some magic switch somewhere to put the engine into thread-safe
> mode
> ? Or is it not supported ? If it is not supported, can I safely assume
> that
> I can at least start one thread that uses dbgeng per process ?
>
> //Daniel
>
>
>
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · September 26, 2012, 2:23pm

I did not say it was “NOT safe”. I said that if it was not designed to be
thread-safe, then its behavior was undefined, and this depended on how it
was designed. According to a later answer, it has its own internal
serialization, so the “If” part I said does not apply.
joe

DBGENG is thread safe as conceptually itself will serialize all calls
(using own global critical section). You could call DBGENG APIs from
multiple threads as this is how WINDBG does.

As earlier post suggested, you could try call DebugCreate() then QI for
different IDebugxxx interfaces from every thread.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@resplendence.com
Sent: Tuesday, September 25, 2012 09:41 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Re:is DbgEng actually thread-safe ?

There is a separate local different object pointer (and everything) for
each thread. I was assuming the threading model was inherited from COM
call through the CoInitialieEx calls and the parameter passed to it.

But Joe says it’s NOT thread-safe. Or should I be sharing one of the
interface pointers between the threads to make it work ?

//Daniel

“Jen-Lung Chiu” wrote in message
> news:xxxxx@windbg…
> DBGENG API IS THREAD SAFE.
>
> One question, how did you share the IDebugControl “interface” pointer
> among the threads?
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@resplendence.com
> Sent: Tuesday, September 25, 2012 09:28 AM
> To: Kernel Debugging Interest List
> Subject: Re:[windbg] is DbgEng actually thread-safe ?
>
> Thanks for your answer. As it shows, even serialzing the jobs will not
> help avoiding the problems. As it appears to me, there can be only one
> thread in a process that makes calls to the engine. Multiple threads are
> not supported, even if only one of them does a DBGENG job at a time.
>
> Another question, is DBGENG using any global or kernel resources that
> would make it not thread-safe even between different processes ? Because
> every process instance gets a fresh copy of DBGENG.DLL, can I spawn as
> many processes as I desire and still achieve multithreading through
> multiple processes ?
>
> //Daniel
>
>
>
> “Joe Ballantyne” wrote in message
> news:xxxxx@windbg…
> No, DbgEng is NOT thread safe.
>
> You will need to synchronize yourself before calling into it.
>
> Joe.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@resplendence.com
> Sent: Tuesday, September 25, 2012 1:15 AM
> To: Kernel Debugging Interest List
> Subject: [windbg] is DbgEng actually thread-safe ?
>
> When I call my dump analysis code from multiple threads, any call to the
> debug engine can fail with E_UNEXPECTED Catastrophic failure. For
> instance:
> :
> IDebugControl::GetNumberProcessors
> IDebugControl::GetPageSize
> IDebugControl::GetStackTrace
>
> If all calls are made from the same thread, there is never an error
> returned.
>
> I have made sure all there are no resources shared between the threads
> whatsoever and that all my own code is thread safe. If I serialize the
> entire routine that uses DbgEng with a critical section, so no multiple
> threads are using the engine at the same time, the problem remains.
>
> Is there some magic switch somewhere to put the engine into thread-safe
> mode ? Or is it not supported ? If it is not supported, can I safely
> assume that I can at least start one thread that uses dbgeng per process ?
>
> //Daniel
>
>
>
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
>
>
>
>
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
>
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Daniel_Terhell · September 26, 2012, 2:45pm

I was talking about Joe Ballantyne. Not about you.

//Daniel

wrote in message news:xxxxx@windbg…
>I did not say it was “NOT safe”. I said that if it was not designed to be
> thread-safe, then its behavior was undefined, and this depended on how it
> was designed. According to a later answer, it has its own internal
> serialization, so the “If” part I said does not apply.
> joe
>
>> But Joe says it’s NOT thread-safe. Or should I be sharing one of the
>> interface pointers between the threads to make it work ?
>>
>> //Daniel
>>
>>