MultiThreading an ActiveX DLL call...

[Cybertof]

Hello,

Is there a good way to call a big time-consumming function from an
ActiveX DLL (interoped) through a thread without blocking the main UI ?

Here are the details :

I have a class CInteropCall encapsulating a call to a visual basic
ActiveX DLL function named FillAlloc_Array Struct_Double() , which is
allocating a big struct array an fills it using a inner loop
(for i = 1 to 300000...)

I'm calling this BigProcess through a thread from the main UI
like this :

CInteropCall MyThreadProcess = new CInteropCall();
Thread m_WorkerThread;
m_WorkerThread = new Thread(new ThreadStart(MyT hreadProcess.Te stMe));
m_WorkerThread. IsBackground = true;
m_WorkerThread. Name = "ThreadLow" ;
m_WorkerThread. Priority = System.Threadin g.ThreadPriorit y.Lowest;
m_WorkerThread. Start();
Here is the TestMe() method from the CInteropCall class which is calling
the function through an instance of a VB6 Class :
public void TestMe()
{
AX_DLL.FillAllo c_ArrayStruct_D ouble(3000000, ref array_struct_do uble);
}
The problem is :
The main UI is blocked when starting the thread, and from time to time
during the thread execution.

Solutions tested :
- adding a Sleep(1) in the inner loop of the vb6 function
It does not change a lot
- adding a DoEvents() in the vb6 function
It does not change a lot but slows down the thread execution.
The same big loop executing from a c# function does not block the main
UI (even without sleep(1)...), the UI remains very smooth.
Any idea to make an interoped vb6 activex call 'UI thread friendly' ?
(or maybe there is no way to do it...)

Regards,
Cybertof.

[Willy Denoyette [MVP]]

"Cybertof" <cy************ @ifrance.com> wrote in message
news:MP******** *************** *@news.wanadoo. fr...

In article <eN************ **@TK2MSFTNGP12 .phx.gbl>,
wi************* @telenet.be says...

Yes, array_stuct = null;
GC.Collect();
forces a GC run and frees the memory taken by the array_stuct, with such
large structs one of the legitime uses of GC.Collect(). What makes you
think
it doesn't run on the background thread?
When done with the COM object your should call
Marshal.Release ComObject(...)
Willy.

Thanks for the hint about the Marshal.Release ComObject(...).

What made me think it does not run on the background thread is :
If I put the GC.Collect() on the big array, it slows down the main UI.
If I remove the GC.Collect(), the main UI is not affected.

Does it sound correct to you ?

GC.Collect() is a static method, not instancied within a thread, so
where does it execute ? It 'touches' all orphelin memory parts, from all
threads within the main process ?
Cybertof.

GC.Collect() forces a full collect, that is all generations are scanned for
non rooted objects during a sweep.
The GC.Collect() obviously runs on the thread that initiated the call (it
calls into the CLR), once started the CLR suspends all managed threads and
prevent all unmanaged threads to return or call into managed code.
Now in your particular case, it might take some time to collect and as such
it might have a visible impact on the UI. Simply put the data you are
handling is too large.
Willy.