Many thanks Andreas! Recently, I was experimenting with some models in 
SmallDEVS, where I started a process with a body:

self socket ifNil: [
    (Delay forSeconds: 1) wait.
].

self socket dataAvailable ifTrue: [
    "do some stuff"
] ifFalse: [
    (Delay forMilliseconds: 20) wait
].

Sometimes this process remained in Process Browser, even though I called 
suspend;terminate. Now I know why. Thanks again,

Elod
> Hi -
>
> Just FYI, I've updated http://bugs.squeak.org/view.php?id=6576 with 
> another change set containing a few relevant tweaks to Delay. The most 
> important one is probably the one which ensures that Delays get 
> unscheduled if the process they wait for is terminated. The problem is 
> that delays which are scheduled are kept in the SuspendedDelays even 
> after "their" process terminates. So that, for example a "(Delay 
> forSeconds: 9999999) wait" (with an Alt-Period following it) would 
> leave that delay being scheduled for expiry 100 days from now although 
> its process is long gone.
>
> The tweaks also ensure that delays which actually expire in 
> Semaphore>>waitTimeoutMSecs: don't get unscheduled twice (since 
> unscheduling is a linear search over all scheduled delays it should be 
> avoided).
>
> Lastly, there is a bit of bullet-proofing to Delay>>handleTimerEvent 
> since each poll of the msecs clock has the potential to overflow and 
> needs to be guarded explicitly. The tweaks make sure there is only one 
> such poll and consequently only one place to check. Except from 
> another obscure situation which the change set addresses as well.
>
> In any case, it's a nice roundup for the Delay changes. If you're 
> using the first one, you should probably use this one as well.
>
> Cheers,
>   - Andreas
>
>