There are a lot of things to consider when analyzing this problem. RB threads are logically cooperative threads, but under the hood use native threads. The RB thread framework takes care of switching contexts for you. So at every for...next, while...wend, and do...loop statement a context switch can occur. Using the DisableBackgroundTasks pragma will turn off this context switching for that method if you like. Since context switching only occurs at the start of a loop, you have to look at the code that runs in between the loop start and end as one non-interruptible block of code. The exception to that is when you call a method that has loops in it that allows a context switch.
Now you are reading a large file of lets say 1.5 mb (just a guess). How much time does it take to read the file in to memory? Whatever that time is on your system, it will freeze your thread for that amount of time. That kind of operation is viewed as an atomic operation since it isn't broke into pieces. When you make a call to read in that file, the OS may be doing other things like reading in other files in the cache to speed up operations down the road. Think of it like the singleton design pattern where the first invocation causes some type of initialization to occur and then subsequent invocations are cheap. Another thing to do is play with the priority of the thread. Set the priority above 5 and see what happens since 5 is normal priority. Set it to 10 and see what happens. The behavior you describe sounds like your thread is being starved for CPU cycles because a higher priority thread is in the queue. Do you keep you thread around when it is done processing the files? If not, perhaps keeping the thread and putting it to sleep until it is needed may make the problem go away since you don't have to go through initialization step. The other thing to try is to see if the behavior is consistent across different OSes (Win32, and Linux). The other thing to consider is if you have other threads running at the same time and what are they doing? Remember that you main application code is consider a thread even if you don't specifically call it a thread. After you call run on the thread are off into an uninterruptible section of code that takes a significant amount of time to execute? This may starve your thread. Bottom line, I don't think you have enough evidence to call it specifically an RB problem. It may be a function of something the OS is doing which is starving your thread or you are just hitting some thread initialization code and then in that case the behavior is by design. Keeping the thread around and putting it to sleep may solve that problem. So go experiment a little more with the above suggestions and then we will have a little more evidence to analyze the problem with. _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
