Smalltalk › Squeak › Squeak - Dev

Some Delay tweaks

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Andreas.Raab

Some Delay tweaks

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

Elod Kironsky

Re: Some Delay tweaks

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
>
>

stephane ducasse

Re: Some Delay tweaks

In reply to this post by Andreas.Raab

will be 3.10 team harvest this change?

Stef

On 31 août 07, at 05:52, Andreas Raab wrote:

> 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
>
>