Um, yes I did - I suggested either a waitable timer or an event. It's impossible to say with certainty what would be the "right" way without more intimate knowledge of the code.
The main thing would be to refactor the worker code into a thread and keep the UI thread doing what it's best at - maintaining the UI - with whatever mechanism is necessary to allow the UI to obtain the information it needs to maintain currency w.r.t the activity in the worker thread(s). On 16 May 2012 14:33, Jeremy Coulter <[email protected]> wrote: > so Jolyon , what would YOU use in this scenario in place of sleep? > You indicated Sleep was prob. not the best solution, but didnt indicate > what would be a GOOD solution :-) > > Jeremy > > On Wed, May 16, 2012 at 9:05 AM, Jolyon Smith <[email protected]>wrote: > >> > Still wondering how a sleep can hang. >> >> This is actually quite easily explained. >> >> Sleep() is an indication to the Windows thread scheduler that your thread >> is willing to relinquish whatever timeslice it currently has. Whether and >> when that thread get's another bite at the CPU is now in the hands of the >> Windows Scheduler. >> >> "Sleep(100)" comes with no guarantee that your thread will resume >> execution after 100 milliseconds, all it ensures is that your thread stops >> running and absolutely won't run again for AT LEAST that time (give or >> take, subject to clock resolution). If there are other higher priority >> threads demanding access to the CPU then your thread can easily find itself >> being shunted to the bottom of the queue until those threads have done ALL >> their work. >> >> Given the nature of the application you describe, which seems to involve >> some sort of multimedia content, I am guessing that even within your >> process - never mind anything else that might be running on the same >> machine - you have one or more other threads that you have most likely set >> to higher than normal priority - the nature of multimedia being what it is, >> you may even have a "realtime" priority thread in the mix somewhere. >> >> That would easily explain why when you relinquish your main UI thread's >> timeslice it doesn't get a look-in until much, much later than you are >> expecting. >> >> _______________________________________________ >> NZ Borland Developers Group - Delphi mailing list >> Post: [email protected] >> Admin: http://delphi.org.nz/mailman/listinfo/delphi >> Unsubscribe: send an email to [email protected] with >> Subject: unsubscribe >> > > > _______________________________________________ > NZ Borland Developers Group - Delphi mailing list > Post: [email protected] > Admin: http://delphi.org.nz/mailman/listinfo/delphi > Unsubscribe: send an email to [email protected] with > Subject: unsubscribe >
_______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe
