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.<br><br>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).<br>
<br><br><br><div class="gmail_quote">On 16 May 2012 14:33, Jeremy Coulter <span dir="ltr"><<a href="mailto:jscoulter@gmail.com" target="_blank">jscoulter@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
so Jolyon , what would YOU use in this scenario in place of sleep?<div>You indicated Sleep was prob. not the best solution, but didnt indicate what would be a GOOD solution :-)</div><span class="HOEnZb"><font color="#888888"><div>
<br></div><div>Jeremy</div></font></span><div><br>
<div class="gmail_quote"><div><div class="h5">On Wed, May 16, 2012 at 9:05 AM, Jolyon Smith <span dir="ltr"><<a href="mailto:jsmith@deltics.co.nz" target="_blank">jsmith@deltics.co.nz</a>></span> wrote:<br></div></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<div><span>> Still wondering how a sleep can hang.</span><div><br></div></div><div>This is actually quite easily explained.<div><br></div><div>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.<br>
<br>"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.</div>
<div><br></div><div>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.<br>
<br>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.<br></div></div>
<br></div></div><div class="im">_______________________________________________<br>
NZ Borland Developers Group - Delphi mailing list<br>
Post: <a href="mailto:delphi@listserver.123.net.nz" target="_blank">delphi@listserver.123.net.nz</a><br>
Admin: <a href="http://delphi.org.nz/mailman/listinfo/delphi" target="_blank">http://delphi.org.nz/mailman/listinfo/delphi</a><br>
Unsubscribe: send an email to <a href="mailto:delphi-request@listserver.123.net.nz" target="_blank">delphi-request@listserver.123.net.nz</a> with Subject: unsubscribe<br></div></blockquote></div><br></div>
<br>_______________________________________________<br>
NZ Borland Developers Group - Delphi mailing list<br>
Post: <a href="mailto:delphi@listserver.123.net.nz">delphi@listserver.123.net.nz</a><br>
Admin: <a href="http://delphi.org.nz/mailman/listinfo/delphi" target="_blank">http://delphi.org.nz/mailman/listinfo/delphi</a><br>
Unsubscribe: send an email to <a href="mailto:delphi-request@listserver.123.net.nz">delphi-request@listserver.123.net.nz</a> with Subject: unsubscribe<br></blockquote></div><br>