Re: [Help-smalltalk] Timeouts for BlockClosures

[Holger Hans Peter Freyther]

On 04/05/2011 08:57 AM, Paolo Bonzini wrote:

Hey,

thanks for your review!


>                 suspended := self isReady not.
>                 block := [self evaluate: [anException signal]
>                     ifNotTerminated: [suspended ifTrue: [self suspend]].
>                 suspendedContext := block asContext: suspendedContext.
>                 self resume]

The issue with the 'self suspend' is that if I use a Delay.. or Socket>>#next
my process is suspended so even if I 'break' the execution of this I will
suspend the process and it will not be woken up. From a VM safety point of
view, is it okay to just continue executing in the unwinded context? My
understanding is that when resuming the process the suspendContext (our
signal) will be executed and we just return from there then.


> 
> Untested---but if you have testcases I'll gladly merge it!  In
> particular, I'd have said the last part could be written as
> 
>        ^[self ensure: [sem signal]]
>               on: TimeoutNotification do: [:e |
>               e block = self
>                 ifTrue:  [^aBlock value]
>                 ifFalse: [e pass] ]
> 
> but I suspect you found out it's not.

It depends of which semantic is nice. I somehow want to have all ensures be
handled before I dispatch the timeout. With the above the timeout would be
before the individual ensures. My test case is testing the order and you could
print the events Collection to see the change.

I have attached my current patch and test case and look forward for another
review of this change.

0001-timeout-Add-code-for-timeout-handling-on-BlockClosur.patch
Description: Text Data