Simple lock up with delay + semaphore - not fixed with 0006576
georg.koester at gmail.com
Sat Jan 5 02:57:44 UTC 2008
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:
| d |
d := Delay timeoutSemaphore: self afterMSecs: (anInteger max: 0).
"Signaling by the Delay here would over-signal the Sem."
A fix would need a sem for the sem I think... is that method usable?
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:
> > I have this fix for my use-case: Avoid
> > |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...
More information about the Squeak-dev