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_ArrayStruct_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(MyThreadProcess.TestMe));
m_WorkerThread.IsBackground = true;
m_WorkerThread.Name = "ThreadLow";
m_WorkerThread.Priority = System.Threading.ThreadPriority.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.FillAlloc_ArrayStruct_Double(3000000, ref array_struct_double);
}
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.
20  3931 
"Cybertof" <cy************@ifrance.com> wrote in message
news:MP************************@news.wanadoo.fr... 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_ArrayStruct_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(MyThreadProcess.TestMe));
m_WorkerThread.IsBackground = true;
m_WorkerThread.Name = "ThreadLow";
m_WorkerThread.Priority = System.Threading.ThreadPriority.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.FillAlloc_ArrayStruct_Double(3000000, ref array_struct_double);
}
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.
You should initialize your (m_WorkerThread) thread to enter an STA. The way
you do it now results in your COM object to run on the main UI thread.
...
m_WorkerThread.ApartmentState = ApartmentState.STA;
m_WorkerThread.Start();
....
Willy.
In article <ej*************@TK2MSFTNGP10.phx.gbl>, wi*************@telenet.be says...
You should initialize your (m_WorkerThread) thread to enter an STA. The way
you do it now results in your COM object to run on the main UI thread.
..
m_WorkerThread.ApartmentState = ApartmentState.STA;
m_WorkerThread.Start();
...
Hi Willy,
That's exactly what I do not want...
I want the thread no to disturb the main UI thread at all.
Cybertof.
"Cybertof" <cy************@ifrance.com> wrote in message
news:MP************************@news.wanadoo.fr... In article <ej*************@TK2MSFTNGP10.phx.gbl>,
wi*************@telenet.be says...
I want the thread no to disturb the main UI thread at all.
Sure, but YOU DO disturb the UI by NOT initializing the background thread to
enter an STA, note this is not the UI thread's apartment but a newly created
apartment.
If you don't initialize your backround thread to enter an STA, the AX object
will enter the UI thread's apartment and calls to methods on this object
will run on the UI thread.
Hope it's clear now.
Willy.
In article <uK**************@TK2MSFTNGP09.phx.gbl>, wi*************@telenet.be says...
Sure, but YOU DO disturb the UI by NOT initializing the background thread to
enter an STA, note this is not the UI thread's apartment but a newly created
apartment.
If you don't initialize your backround thread to enter an STA, the AX object
will enter the UI thread's apartment and calls to methods on this object
will run on the UI thread.
Hope it's clear now.
Willy.
Thanks, it's more clear.
And should the VB6 ActiveX be compiled with
'Single Threaded' or 'Apartment Threaded' ?
Regards,
Cybertof.
"Cybertof" <cy************@ifrance.com> wrote in message
news:MP************************@news.wanadoo.fr... In article <uK**************@TK2MSFTNGP09.phx.gbl>,
wi*************@telenet.be says...
Sure, but YOU DO disturb the UI by NOT initializing the background thread
to
enter an STA, note this is not the UI thread's apartment but a newly
created
apartment.
If you don't initialize your backround thread to enter an STA, the AX
object
will enter the UI thread's apartment and calls to methods on this object
will run on the UI thread.
Hope it's clear now.
Willy.
Thanks, it's more clear.
And should the VB6 ActiveX be compiled with
'Single Threaded' or 'Apartment Threaded' ?
Regards,
Cybertof.
Apartment.
Willy.
In article <#E*************@tk2msftngp13.phx.gbl>, wi*************@telenet.be says...
"Cybertof" <cy************@ifrance.com> wrote in message
news:MP************************@news.wanadoo.fr... In article <uK**************@TK2MSFTNGP09.phx.gbl>,
wi*************@telenet.be says...
Apartment.
Willy.
STA...Appartment...no changes.
I think it's not a problem of thread :
A very very long time is spent during parameter passing.
My array is passe byref, I don't understand why it takes so long time.
Is there any method to pass efficiently an array as a parm to a VB6
ActiveX DLL function ?
Regards,
Cybertof.
"Cybertof" <cy************@ifrance.com> wrote in message
news:MP************************@news.wanadoo.fr... In article <#E*************@tk2msftngp13.phx.gbl>,
wi*************@telenet.be says...
"Cybertof" <cy************@ifrance.com> wrote in message
news:MP************************@news.wanadoo.fr... > In article <uK**************@TK2MSFTNGP09.phx.gbl>,
> wi*************@telenet.be says...
Apartment.
Willy.
STA...Appartment...no changes.
I think it's not a problem of thread :
A very very long time is spent during parameter passing.
My array is passe byref, I don't understand why it takes so long time.
Is there any method to pass efficiently an array as a parm to a VB6
ActiveX DLL function ?
Regards,
Cybertof.
Are you sure that you create the instance of your COM object, and call the
COM method in the same thread procedure?
Failing to do so will incur thread marshaling overhead!
So the STA threading rules are simple;
- initialize your thread to enter an STA.
- call the COM object's methods on the same thread as the one that created
the object instance.
Willy.
In article <uk**************@TK2MSFTNGP14.phx.gbl>, wi*************@telenet.be says... Are you sure that you create the instance of your COM object, and call the
COM method in the same thread procedure?
Failing to do so will incur thread marshaling overhead!
So the STA threading rules are simple;
- initialize your thread to enter an STA.
- call the COM object's methods on the same thread as the one that created
the object instance.
Willy.
Yes, I'm sure, everything is done in the same thread.
As another example, I have removed the 2nd thread creation, and made the
call directly behing a button_click in the main UI Thread.
It's slow when passing the array to the VB6 AX Function, and returning
from the function.
It seems like the array is entirely copied instead of beeing passed
byref. (even if the ref keyword is used during the call...)
Any idea ?
"Cybertof" <cy************@ifrance.com> wrote in message
news:MP************************@news.wanadoo.fr... In article <uk**************@TK2MSFTNGP14.phx.gbl>,
wi*************@telenet.be says...
Are you sure that you create the instance of your COM object, and call
the
COM method in the same thread procedure?
Failing to do so will incur thread marshaling overhead!
So the STA threading rules are simple;
- initialize your thread to enter an STA.
- call the COM object's methods on the same thread as the one that
created
the object instance.
Willy.
Yes, I'm sure, everything is done in the same thread.
As another example, I have removed the 2nd thread creation, and made the
call directly behing a button_click in the main UI Thread.
It's slow when passing the array to the VB6 AX Function, and returning
from the function.
It seems like the array is entirely copied instead of beeing passed
byref. (even if the ref keyword is used during the call...)
Any idea ?
Ok, don't mix two different issues, speed and UI responsiveness. Your
initial issue was that the UI thread was blocked for the duration of the
call, the solution for this was to move this to a background thread, right?
Well, is this issue solved?
If it is, we can have a look at the speed issue, a few questions come to
mind though, how's the speed compared to a VB6 client calling into your
object? Could you post some code?
Willy.
In article <OY**************@TK2MSFTNGP10.phx.gbl>, wi*************@telenet.be says...
"Cybertof" <cy************@ifrance.com> wrote in message
news:MP************************@news.wanadoo.fr... In article <uk**************@TK2MSFTNGP14.phx.gbl>,
wi*************@telenet.be says...
Ok, don't mix two different issues, speed and UI responsiveness. Your
initial issue was that the UI thread was blocked for the duration of the
call, the solution for this was to move this to a background thread, right?
Well, is this issue solved?
If it is, we can have a look at the speed issue, a few questions come to
mind though, how's the speed compared to a VB6 client calling into your
object? Could you post some code?
Willy.
Well, the first issue is not totally solved :
Moving the call within a background thread (STA or not) gives more
responsive to the UI, but still blocks it from time to time, which does
occur only at all with the call to the ActiveX DLL Method, so I supposed
there is a thread problem with big arrays beeing passed to an ActiveX,
even if the background thread instanciates the ActiveX Class and calls
it from there.
Let's try to solve the 'Speed problem first' (easier as no background
thread is involved).
Here is some code :
*******************
VB6 ACTIVEX DLL : (in a Class named CTest)
*******************
Type VBStruct
d As Date
e As Integer
o As Double
h As Double
l As Double
c As Double
v As Long
oi As Long
End Type
Public Sub TestCall(ByRef data() As VBStruct)
MsgBox "FillArrayStruct_Double : INSIDE AX CALL" // L4
End Sub
**********************
C# Test Application : (AX_DLL is the namespace viewed from c#)
**********************
AX_DLL.CTest MyTest; // Active X DLL
AX_DLL.VBStruct[] array_struct = null;
MyTest = new AX_DLL.CTest();
startTime = DateTime.Now.Ticks;
MessageBox.Show("before alloc...");
array_struct = new AX_DLL.VBStruct[3000000]; // L1
MessageBox.Show("before ax call"); // L2
AX_DLL.TestCall(ref array_struct_double); // L3
MessageBox.Show("after ax call"); // L5
With this code, 'L1' is immediate to execute,
but, it takes quite some long time to go from
L2->L3->L4, and same long time to go through
L4->L5.
If you replace L1 with
array_struct = new AX_DLL.VBStruct[10]; // L1
everything gets very fast, no wait between calls...
The only cause of the slowness is passing a big array as a parameter.
Do you have an idea ?
Regarding the thread issue, if I put all the C# code above inside a
background STA Thread, the main UI stills blocks approximatively at the
same lines...
Regards,
Cybertof.
Code Update (L3 was wrong)
Please replace
AX_DLL.TestCall(ref array_struct_double); // L3
with
MyTest.TestCall(ref array_struct_double); // L3
"Cybertof" <cy************@ifrance.com> wrote in message
news:MP***********************@news.wanadoo.fr... In article <OY**************@TK2MSFTNGP10.phx.gbl>,
wi*************@telenet.be says...
"Cybertof" <cy************@ifrance.com> wrote in message
news:MP************************@news.wanadoo.fr... > In article <uk**************@TK2MSFTNGP14.phx.gbl>,
> wi*************@telenet.be says...
Ok, don't mix two different issues, speed and UI responsiveness. Your
initial issue was that the UI thread was blocked for the duration of the
call, the solution for this was to move this to a background thread,
right?
Well, is this issue solved?
If it is, we can have a look at the speed issue, a few questions come to
mind though, how's the speed compared to a VB6 client calling into your
object? Could you post some code?
Willy.
Well, the first issue is not totally solved :
Moving the call within a background thread (STA or not) gives more
responsive to the UI, but still blocks it from time to time, which does
occur only at all with the call to the ActiveX DLL Method, so I supposed
there is a thread problem with big arrays beeing passed to an ActiveX,
even if the background thread instanciates the ActiveX Class and calls
it from there.
Let's try to solve the 'Speed problem first' (easier as no background
thread is involved).
Here is some code :
*******************
VB6 ACTIVEX DLL : (in a Class named CTest)
*******************
Type VBStruct
d As Date
e As Integer
o As Double
h As Double
l As Double
c As Double
v As Long
oi As Long
End Type
Public Sub TestCall(ByRef data() As VBStruct)
MsgBox "FillArrayStruct_Double : INSIDE AX CALL" // L4
End Sub
**********************
C# Test Application : (AX_DLL is the namespace viewed from c#)
**********************
AX_DLL.CTest MyTest; // Active X DLL
AX_DLL.VBStruct[] array_struct = null;
MyTest = new AX_DLL.CTest();
startTime = DateTime.Now.Ticks;
MessageBox.Show("before alloc...");
array_struct = new AX_DLL.VBStruct[3000000]; // L1
MessageBox.Show("before ax call"); // L2
AX_DLL.TestCall(ref array_struct_double); // L3
MessageBox.Show("after ax call"); // L5
With this code, 'L1' is immediate to execute,
but, it takes quite some long time to go from
L2->L3->L4, and same long time to go through
L4->L5.
If you replace L1 with
array_struct = new AX_DLL.VBStruct[10]; // L1
everything gets very fast, no wait between calls...
The only cause of the slowness is passing a big array as a parameter.
Do you have an idea ?
Regarding the thread issue, if I put all the C# code above inside a
background STA Thread, the main UI stills blocks approximatively at the
same lines...
Regards,
Cybertof.
Eek!!, an array of 3000000 structs (UDT in VB), I thought you were talking
about doubles. Not suprisingly it takes some time to call a method what did
you expect?
Your array takes 3M * 48 bytes ~140MB managed memory + the same amount
because it must be marshaled to unmanaged memory. That means ~300MB of
Memory taken by this single array.
If you don't have that amount free RAM - and I guess THAT'S YOUR PROBLEM,
the system will start trashing, and the time to marshal the call can tens of
seconds maybe minutes. Even if you have that amount of memory free, it will
take several seconds maybe ten to marshal.
I'm not clear why you need to pass such amount of data between managed and
unmanaged world, but this is not the best solution anyway.
Willy.
In article <u7*************@TK2MSFTNGP10.phx.gbl>, wi*************@telenet.be says...
Eek!!, an array of 3000000 structs (UDT in VB), I thought you were >>
talkingabout doubles. Not suprisingly it takes some time to call a method what
did
you expect?
Your array takes 3M * 48 bytes ~140MB managed memory + the same amount
because it must be marshaled to unmanaged memory. That means ~300MB of
Memory taken by this single array.
If you don't have that amount free RAM - and I guess THAT'S YOUR >
PROBLEM,the system will start trashing, and the time to marshal the call can >
tens ofseconds maybe minutes. Even if you have that amount of memory free, it
will
take several seconds maybe ten to marshal.
I'm not clear why you need to pass such amount of data between managed
and
unmanaged world, but this is not the best solution anyway.
Willy.
Willy,
Thanks for your answer.
3000000 was for exagerating the test, because I have also noticed some
slowness in smaller arrays.
Ok for the speed needed, but why does it block the main UI Thread even
when the c# is in a backgroud STA thread ?
The idea of the background thread is not to slow the UI, even with a
long task duration (like this one).
In this case, the code is launched from the main UI Thread :
Thread m_WorkerThread;
m_WorkerThread = new Thread(new ThreadStart(MyThreadProcess.TestMe));
m_WorkerThread.IsBackground = true;
m_WorkerThread.Name = "ThreadNormal";
m_WorkerThread.ApartmentState = System.Threading.ApartmentState.STA;
m_WorkerThread.Priority = System.Threading.ThreadPriority.Normal;
m_WorkerThread.Start();
(MyThreadProcess is an instance of a class making the call in my
previous code, through the TestMe method)
If I put a lower priority, it does not change, from time to time, the
main UI Thread still blocks...
Christophe.
"Cybertof" <cy************@ifrance.com> wrote in message
news:MP************************@news.wanadoo.fr... In article <u7*************@TK2MSFTNGP10.phx.gbl>,
wi*************@telenet.be says...
Eek!!, an array of 3000000 structs (UDT in VB), I thought you were >>
talkingabout doubles. Not suprisingly it takes some time to call a method what
did
you expect?
Your array takes 3M * 48 bytes ~140MB managed memory + the same amount
because it must be marshaled to unmanaged memory. That means ~300MB of
Memory taken by this single array.
If you don't have that amount free RAM - and I guess THAT'S YOUR >
PROBLEM,the system will start trashing, and the time to marshal the call can >
tens ofseconds maybe minutes. Even if you have that amount of memory free, it
will
take several seconds maybe ten to marshal.
I'm not clear why you need to pass such amount of data between managed
and
unmanaged world, but this is not the best solution anyway.
Willy.
Willy,
Thanks for your answer.
3000000 was for exagerating the test, because I have also noticed some
slowness in smaller arrays.
Ok for the speed needed, but why does it block the main UI Thread even
when the c# is in a backgroud STA thread ?
The idea of the background thread is not to slow the UI, even with a
long task duration (like this one).
In this case, the code is launched from the main UI Thread :
Thread m_WorkerThread;
m_WorkerThread = new Thread(new ThreadStart(MyThreadProcess.TestMe));
m_WorkerThread.IsBackground = true;
m_WorkerThread.Name = "ThreadNormal";
m_WorkerThread.ApartmentState = System.Threading.ApartmentState.STA;
m_WorkerThread.Priority = System.Threading.ThreadPriority.Normal;
m_WorkerThread.Start();
(MyThreadProcess is an instance of a class making the call in my
previous code, through the TestMe method)
If I put a lower priority, it does not change, from time to time, the
main UI Thread still blocks...
Christophe.
Again, I guess your COM object runs on the UI thread. Changing the priority
makes no sense, the CLR doesn't care about it when marshaling between
threads.
Beware if you create the instance of the COM object in MyThreadProcess
constructor, you are effectively creating an instance on the UI thread.
Please post your thread procedure or better the MyThreadProcess, the part
that creates the thread doesn't tell where you create an instance of the COM
object.
Also needed are some figures like your OS and memory size, framework
version...
Willy.
In article <ej**************@TK2MSFTNGP12.phx.gbl>, wi*************@telenet.be says... Beware if you create the instance of the COM object in MyThreadProcess
constructor, you are effectively creating an instance on the UI thread.
Willy,
You were right....the instanciation of the ActiveX was done in the
constructor, so in the main UI !
I have moved the instanciation to the method, and now it's better.
Last question :
How do you release memory allocated like this :
array_struct = new AX_DLL.VBStruct[3000000];
Is
array_stuct = null;
enough with the marshalling ?
I have tried to call a GC.Collet() inside the thread before it
terminates, but GC.Collet() does not seem to run into the background
thread, does it ?
Regards,
Cybertof.
"Cybertof" <cy************@ifrance.com> wrote in message
news:MP***********************@news.wanadoo.fr... In article <ej**************@TK2MSFTNGP12.phx.gbl>,
wi*************@telenet.be says...
Beware if you create the instance of the COM object in MyThreadProcess
constructor, you are effectively creating an instance on the UI thread.
Willy,
You were right....the instanciation of the ActiveX was done in the
constructor, so in the main UI !
I have moved the instanciation to the method, and now it's better.
Last question :
How do you release memory allocated like this :
array_struct = new AX_DLL.VBStruct[3000000];
Is
array_stuct = null;
enough with the marshalling ?
I have tried to call a GC.Collet() inside the thread before it
terminates, but GC.Collet() does not seem to run into the background
thread, does it ?
Regards,
Cybertof.
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.ReleaseComObject(...)
Willy.
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.ReleaseComObject(...)
Willy.
Thanks for the hint about the Marshal.ReleaseComObject(...).
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.
If you open up mscorlib.dll with ILDASM and look at GC.Collect() you will see
it eventually gets to the private method GC.nativeCollectGeneration(). You
will see that this is marked with the pseudoattibute "internalcall" and that
the actual code of it is blank. This is because the Collection occures within
the .NET Runtime itself and not anywhere in your code.
However, it still poses a bigger threat. Since GC works with "generations",
whenever Garbage Collection occures, the entire Runtime for that application
will pause during collection, reguardless of threads. I would recommend
setting what you don't need as null, but don't call collection. When GC does
happen on it's own and it sees that it is null, it won't hesitate to collect
it.
Another factor about collection is resurrection. Resurrection is exactly as
it sounds. When an application is no longer accessing a live object, the
garbage collector considers the object to be dead. However, if the object
requires finalization, the object is considered live again until it is
actually finalized, and then it is permanently dead. In other words, an
object requiring finalization dies, lives, and then dies again. When the
object is going to be finalized, avoid multiple resurections, or worse, a
loop where the object is called for finalization, resurrected, and then set
for finalization again, then finalized, so it get's stuck.
Be careful when working with static or global objects as well. Something
like this would hurt:
public class BaseObj {
~BaseObj() {
Application.ObjHolder = this;
}
}
class Application {
public static Object ObjHolder; // Defaults to null
....
}
Note about how GC works in the Framework, objects that are 20,000 bytes or
larger are placed on a special heap. This is transparent so the developer nor
the actual code itself will know it. As far as it is concerned, it is one
heap. The reason for this is the special heap is never compacted. Shifting
20,000 bytes or more down the heap will require too much CPU time.
Generally I would recommend not calling collection on your own unless you
have very good reasons.
"Cybertof" wrote: 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.ReleaseComObject(...)
Willy.
Thanks for the hint about the Marshal.ReleaseComObject(...).
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.
"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.ReleaseComObject(...)
Willy.
Thanks for the hint about the Marshal.ReleaseComObject(...).
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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Mark Sisson |
last post by:
Hey all.
I've got a legacy COM dll that I'd like to use in my multithreaded C#
app. Problem though is when I create several instances of the interop
object and start them on their own threads...
|
by: Marwan |
last post by:
Hello
I am using asynchronous delegates to make a call to a COM ActiveX object, but even though the call occurs on a separate thread, my UI is still blocking.
If i put the thread to sleep in my...
|
by: Ed |
last post by:
Here's my situation, I am moving some of my apps over from native C++
(primarily Win32 and MFC).
One of these apps uses some COM objects in worker threads running in the
background where it...
|
by: Mark Yudkin |
last post by:
The documentation is unclear (at least to me) on the permissibility of
accessing DB2 (8.1.5) concurrently on and from Windows 2000 / XP / 2003,
with separate transactions scope, from separate...
|
by: tommy |
last post by:
hi,
i have found a example for multithreading and asp.net
http://www.fawcette.com/vsm/2002_11/magazine/features/chester/
i want to speed up my website ...
if my website is starting, they...
|
by: shonend |
last post by:
**** sorry about the length of the message. If you can't read the
whole thing and still willing to help, read the last 2 paragraphs where
the main problem is described. The introduction story is...
|
by: Yeti |
last post by:
Hey everyone, I am modifying code upgraded from VB 6 to 2005. I need to run
the 2005 code in the MTA mode so I set a sub main procedure in my module
which runs first when the program starts:
...
|
by: boo73uk |
last post by:
Hi All,
I'm going to rewrite a VB6 app to VB.net and I need some pointers.
Basically this app spawns simultaneous,multiple, independant
ActiveX.exe 'workers' which query a SQL Server database and...
|
by: Pradnya Patil |
last post by:
hi ,
I am trying to draw ' html div-tag ' on the screen which will
resemble a rectangle through vb.net code.
I want it to be drawn faster...so I introduced multithreading
using Threadpool. I...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
| |
