Application hang and CPU priority.

R

Reapz

Well-known member
Joined
Dec 15, 2002
Messages
74
My app gathers information from lots of large text files which can take quite a while. I have managed to make this process as quick as possible but I have two questions...

1) During the compile process the user is given progress feedback and other info in a scrollable textbox like most apps of its kind. Thing is... If I try to scroll that box while the process is still running the app hangs. Infact if I try to do anything else at all (minimise, run another program etc...) while the process is running the app hangs. What can I do to prevent this?

2) I have put a check box on the form that will allow the user to choose whether the app has low or normal CPU priority (labelled Run the in background) but I have no clue how to go about this so some pointers would be appreciated.

Cheers,
Andy.
 
for question 1 have a look at the BeginRead method of the stream class. This will allow you to handle the reads asyncronously (sp?) and prevent blocking in your UI.

as for question 2 something along the lines of
Code: 
system.Threading.Thread.CurrentThread.Priority=Threading.ThreadPriority.BelowNormal

should do it.
 
Ok question 2 is sorted. Cheers for that!

I forgot to mention that although mostly the program hangs if I try to do anything else, occasionally it wont even let me scroll or minimze it. If for example I click the minimize button, the app doesnt minimze until compiling is complete.
 
You could try running your various file processes in a seperate thread. That way you can be sure that your window wont be held up by the other processes. You can then set the priority to Lowest for this thread but keep your program on normal.

Handling multiple threads can get tricky, especially when prematurely killing a thread, but its extremely powerful.


Theres a great section in the MSDN library about using threads and threading (http://msdn.microsoft.com/library/d...s/cpguide/html/cpconusingthreadsthreading.asp). Have a read of that and try playing around with creating your own threads. Im currently learning this for my own application (Ive got a function that scans the harddrive for specific files) so if youve got any further questions I might be able help out.
 
Excellent! Cheers!

Seems to run great now. However, because this is the first time Ive used threads Ill run through what I did...

Publicly declared the thread...
Code: 
Public CompileThread As System.Threading.Thread
Then created a new instance of the thread when the Start Compile button is pressed and started it immediately...
Code: 
CompileThread = New System.Threading.Thread(AddressOf CompileLogs)
CompileThread.Start()
Where CompileLogs is the sub with all the code in.

At the end of that sub I stop the thread...
Code: 
CompileThread.Abort
Like I said this works a treat but Im just wondering if theres something else I need to do to avoid any as yet unencountered probs.

Thanks again!
 
Looks good to me. You can set priority with CompileThread.Priority = [whatever].

Note than when you do Thread.Abort, then an ThreadAbortException is thrown in the thread. This can be handled but not supressed in the function, so youll need to have something like:

Code: 
Try
           CompileThread.Abort
Catch e as ThreadAbortException
           Everthings ok, thread abort exception
End Try

Another useful command is Thread.Join. This waits for the thread to abort (doing Thread.Abort isnt instant(. Calling Thread.Join after doing an abort will hold the code until the thread has sucesfully been terminated.

Have fun!
 
Theres always something isnt there?...

As I said, I thought everything was working perfectly but there is a problem after all.

When I try to close the app at any point after running the CompileLogs sub in the CompileThread described above it throws an Object reference not set to instance of object exception at me on the line...
Code: 
MyBase.Dispose(disposing)
At first I didnt think it was anything to do with the thread because I have another process which runs in a different thread (not at the same time) which does not produce this problem.

Anyway, I removed the CompileThread and called the subroutine normally and the error disappeared so obviously it is but not knowing enough about threads Im buggered if I know why it does it after running one sub but not the other.

The only difference in the subroutines is that CompileLogs does a lot more with the data from the logfiles and runs for a lot longer than the other one.
 
Try:
Code: 
CompileTread.IsBackground = true
Threads in the background will automatically close down when the foreground thread (your application) closes. If you dont set your thread to background, then you have to explicitly end it (with the CompileThread.Abort ... CompileThread.Join.

Other than that setting a thread to background makes no difference.
 
Back
Top