I have a program that copies a .zip file from one directory to another and unzips it. I use background worker for this.
Now the program works when it's started using the Visual Studio Start button or double clicked directly from Debug/program.exe, but when I copy this .exe file elsewhere, it starts properly doing some operations on the main thread, but the background worker doesn't seem to work.
Does anyone have any clue what's going on?
Note to self: Always remember about third-party .dll files. I didn't have them in my output directory so the program wasn't working. Thanks #KoBE.
It is looks like main thread finished, while Background thread do not finished his work. I think you need in main thread wait until background thread finished. You can use synchronization objects, for example Manual/Auto reset events.
Scheme is simple:
1. In main thread you starts some background thread
2. Before main thread finished, it shall wait until background thread finished working
3. When background thread finished working, main thread can be finished too
In debug mode because of delays and breakpoints in main thread, background thread has enough time to finish his work
Related
I have Main() function which displays in label the current time. There is a button which calls a function LoadUserImage() for reading image files and writing them to database and then showing the result of reading and writing in another label. While LoadUserImage() is running I want the Main() function to still display in label the current time. My instructor tells me to put LoadUserImage() in a separate thread and then join it. But on his lectures he tells that Thread.Join() makes the main thread kind of pause temporarily The question is: if joining makes the main thread pause then how can it update the GUI in my case?
The purpose of Thread.Join() is to make sure that the background thread started previously is stopped properly, but it is not needed for the background thread to work.
In your case, you start the long-running operation in a background thread, and in the main thread proceed with the other activities. You need to call Thread.Join() only at the end, when the main thread has already finished its activity. If at that point the background thread had terminated already, Thread.Join() will return right away, while if the background thread is still busy, it will block (in the main thread) until the background thread has finished. This is the way to make sure an app is not exiting until operations are active in the background.
I suppose in your Main() (running in the main thread) you have some loop which periodically updates some UI. This loop has some exit condition (e.g. by reacting to pressing Enter in a Console.ReadLine(), or a Ctrl-C handler). Once the loop is exited, it can call Thread.Join().
If proper exit is not implemented at all in your sample program (which is not so nice, but usual in such sample program), then you don't have to call Thread.Join() at all! When the process exits, all threads disappear anyways.
I have some difficulty debugging a multithread app. So I set up a breakpoint in a worker thread and application hits it, but when I try to resume it just doesn't continue execution. It should end worker thread and then comeback to main form, but worker thread popup (it spawns a small form) just stays there forever. In addition, when I tried to break execution after that "continue" Visual Studio stops at Application.Run(...). My goal is to debug few lines in worker and see effects in main form. Anyone experienced that issue? Or maybe it is not an issue at all?
Spawning UI on worker threads is not a good idea. If your thread is not a primary UI thread, then do not create or update UI Elements on it.
If you are in WPF, you would need to use something like Application.Current.Dispatcher.Invoketo create or update UI on the proper thread.
Using System.Threading.Thread.Sleep( ) makes the entire application stop for the time taken in the arguments. I want other processes running while one process is waiting for a particular amount of time. To put it in short, I want another way other than System.Threading.Thread.Sleep( ) in my application that does not stop the entire thing.
Example: If I have a label that changes text every 5 seconds, I should be able to press a button which can do some other process, like changing an image.
Thread.Sleep() only puts the current thread to sleep. If it is the UI thread, this might block your application and it looks like it is completely blocked. Background threads are still running.
If you want to sleep without blocking, you could use the following code:
await Task.Delay(5000);
// continue here with your code, such as updating your label
This doesn't block the UI thread, just delays the proceeding of your function. You have to declare your method as async
I am not too informed about this so I am not sure this is the best way to do it
The Task.Wait Method
like that your main thread waits for the child thread to complete before continuing. From here on to your problem I guess just brains will help
an other helpful link:
Thread Synchronization
I'm trying to figure out why the application process lingers in Task Manager after the application is closed and the window disappears.
When I get VS to attach to the zombie process and break all, the threads window shows that the main thread is still alive, and a number of worker threads as well.
Some questions:
Are worker threads necessarily background threads? If not, how do I identify the background threads as I didn't see such a column in the window?
Do I simply double-click on each thread in the thread window, and watch the Thread.IsBackgroundThread value?
When I click on the main thread, the debugger doesn't show a call stack. How
do I identify where the main thread is stuck?
I would strongly sugest you tu use WinDbg. It is not a visual debugger though it is much more powerful.
Surely I will figure you out.
To list all threads in a process use: ~.
To switch to a certain thread ~thread_ids.
To see stak of curent thread !clr_stack.
Brief tutorial.
http://www.codeproject.com/KB/debug/windbg_part1.aspx
Also try in google "Debuging Asp.net with windbg"
Experimenting with the TcpClient and TcpListener class and for some reason when I have a couple of threads running and I close the form the process does not end but the form disappears.
I have to manually kill the process with the VS IDE or task manager.
Nothing in the form is still running from what I can tell when I close the program but the process does not end.. I insert breakpoints everywhere and even the console output says the threads exited.
Anyone know what's going on here?
The main thread of your application is waiting for the threads your spawned to finish. You can set the IsBackground property of your threads to true so they do not stop your process from terminating:
From MSDN:
A thread is either a background thread or a foreground thread.
Background threads are identical to foreground threads, except that
background threads do not prevent a process from terminating. Once all
foreground threads belonging to a process have terminated, the common
language runtime ends the process. Any remaining background threads
are stopped and do not complete.