bug in delay?
jmdc_marcelo at yahoo.com.ar
Mon Jan 5 17:59:09 UTC 2004
>Mmm, I seem to recall Dan Ingalls, Bill Shauck, Samuel S. Shuster and I
>were in there a few years back to
>prove that the clock roll over logic had a bug where it wouldn't reset
>the resumption time correctly in certain cases. Leaving
>Dan's weather station software hung.
>Assuming we are talking about SuspendedDelays which is created as:
>[:d1 :d2 | d1 resumptionTime <= d2 resumptionTime].
>I would suggest you look at all users of SuspendedDelays in your image
>and confirm that it's protected by
>AccessProtect. In a quick look before adequate coffee I don't see why
>it's broken if I assume something is altering
>SuspendedDelays as the add: logic is running. You might need to look
>at callers of certain methods to find the wrapping
** here is where the stack trace show the error
this colaboration occurs into AccesProtect critical
"Private! Schedule this Delay, but return immediately rather than waiting.
The receiver's semaphore will be signalled when its delay duration has
beingWaitedOn ifTrue: [self error: 'This Delay has already been
AccessProtect critical: [
beingWaitedOn _ true.
resumptionTime _ Time millisecondClockValue + delayDuration.
ActiveDelay == nil
ifTrue: [self activate]
resumptionTime < ActiveDelay resumptionTime
SuspendedDelays add: ActiveDelay.
ifFalse: [SuspendedDelays add: self (** HERE FIRE ERROR ) ]]].
¿Buscás un auto?
Encontralo en Yahoo! Autos
¡Más de 4000 clasificados todos los días!
Usados - 0 km - Vendé el tuyo
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev