Hi Tom,<br><br>Thanks for the quick response!<br><br>I thought the semaphore gets set as the semaphore that is signaled later... well the code is complicated.<br><br>I have another question:<br>Semaphore>>waitTimeoutMSecs:
<br>| d |<br> d := Delay timeoutSemaphore: self afterMSecs: (anInteger max: 0).<br> self wait.<br> "Signaling by the Delay here would over-signal the Sem."
<br> d unschedule.<br><br>A fix would need a sem for the sem I think... is that method usable?<br><br>Cheers again,<br>Georg<br><br><div class="gmail_quote">On Jan 5, 2008 12:37 AM, Tom Phoenix <<a href="mailto:rootbeer@redcat.com">
rootbeer@redcat.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On Jan 4, 2008 2:58 PM, Georg Köster <
<a href="mailto:georg.koester@gmail.com">georg.koester@gmail.com</a>> wrote:<br><br>> Delay timeoutSemaphore: s afterMSecs: 1.<br><br></div>Despite the comment in the source code, Delay<br>class>>timeoutSemaphore:afterMSecs: doesn't signal the given
<br>semaphore; in fact, it never uses that parameter. That method should<br>be deprecated, if not simply removed. I've filed a bug report:<br><br> <a href="http://bugs.squeak.org/view.php?id=6834" target="_blank">http://bugs.squeak.org/view.php?id=6834
</a><br><div class="Ih2E3d"><br>> I have this fix for my use-case: Avoid Delay>>timeoutSempaphore:afterMSecs:<br><br>> |s|<br>> s := Semaphore new.<br>> [(Delay forSeconds:1) wait. s signal.] fork.<br>> s wait.
<br>> Transcript show: 'Now gets here - line will be printed'; cr.<br><br>> Resource intense, I know.<br><br></div>Why; because you used fork? Squeak processes don't work the way you<br>might think. I would recommend a solution along those exact lines.
<br><br>Hope this helps!<br><font color="#888888"><br>--Tom Phoenix<br><br></font></blockquote></div><br>