Hi Tom,

Thanks for the quick response!

I thought the semaphore gets set as the semaphore that is signaled later...
well the code is complicated.

I have another question:
Semaphore>>waitTimeoutMSecs:
| d |
    d := Delay timeoutSemaphore: self afterMSecs: (anInteger max: 0).
    self wait.
    "Signaling by the Delay here would over-signal the Sem."
    d unschedule.

A fix would need a sem for the sem I think... is that method usable?

Cheers again,
Georg

On Jan 5, 2008 12:37 AM, Tom Phoenix <rootbeer at redcat.com> wrote:

> On Jan 4, 2008 2:58 PM, Georg Köster <georg.koester at gmail.com> wrote:
>
> > Delay timeoutSemaphore: s afterMSecs: 1.
>
> Despite the comment in the source code, Delay
> class>>timeoutSemaphore:afterMSecs: doesn't signal the given
> semaphore; in fact, it never uses that parameter. That method should
> be deprecated, if not simply removed. I've filed a bug report:
>
>    http://bugs.squeak.org/view.php?id=6834
>
> > I have this fix for my use-case: Avoid
> Delay>>timeoutSempaphore:afterMSecs:
>
> > |s|
> > s := Semaphore new.
> > [(Delay forSeconds:1) wait. s signal.] fork.
> > s wait.
> > Transcript show: 'Now gets here - line will be printed'; cr.
>
> > Resource intense, I know.
>
> Why; because you used fork? Squeak processes don't work the way you
> might think. I would recommend a solution along those exact lines.
>
> Hope this helps!
>
> --Tom Phoenix
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080105/fc67f247/attachment.htm