Funny Delay timer bug with image suspend and resumption

Hi,

thanks to yours and Gwenael's work I move from screen/gst to image and
gst-remote. Today I have found a funny bug and look for some hints.


$ gst
st> Smalltalk at: #PROC put: [
        [(Delay forSeconds: 3) wait. 'Timedout' printNl] repeat] fork]]
st> stdin next
'Timedout'
'Timedout'
$<10>
st> ObjectMemory snapshot: 'foo.img'
'Timedout'
"Global garbage collection... done"
false



$ gst -I foo.img
st> stdin next

$<10>
st> Delay allInstances
(a Delay )
st> Delay allInstances inspect
An instance of WeakArray
  values: (a Delay )
  nilValues: ByteArray (0 )
  contents: [
    [1]: a Delay
  ]
(a Delay )
st> Delay allInstances first inspect
An instance of Delay
  resumptionTime: 55463
  delayDuration: 3000
  delaySemaphore: Semaphore(nil: held, 1 waiting processes)
  waitingProcess: nil
a Delay


any idea where I should start looking at?



_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Wed, Sep 21, 2011 at 19:24, Holger Hans Peter Freyther
<[hidden email]> wrote:
> Hi,
>
> thanks to yours and Gwenael's work I move from screen/gst to image and
> gst-remote. Today I have found a funny bug and look for some hints.

So you want the value of the millisecond clock to be restored when you
resume a snapshot?  Makes sense.

> any idea where I should start looking at?

Either we do it on the VM, or start by making "Time class" a dependent
of ObjectMemory.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 09/21/2011 11:22 PM, Paolo Bonzini wrote:
> On Wed, Sep 21, 2011 at 19:24, Holger Hans Peter Freyther
> <[hidden email]> wrote:
>> Hi,
>>
>> thanks to yours and Gwenael's work I move from screen/gst to image and
>> gst-remote. Today I have found a funny bug and look for some hints.
>
> So you want the value of the millisecond clock to be restored when you
> resume a snapshot?  Makes sense.

but there must be more to this. E.g. even if I save the image near millisecond
clock of 0... the task does not run..


$ cat cat foo.st
Eval [
        Time millisecondClockValue printNl.
        Smalltalk at: #FOO put: [
        [(Delay forSeconds: 3) wait. Time millisecondClockValue printNl] repeat] fork.

        ObjectMemory snapshot: 'foo.img'.
        stdin next
]


$ gst -i foo.st
"Global garbage collection... done"
0
"Global garbage collection... done"
3001
6001
^CObject: FileStream new "<-0x4c82c6a0>" error: interrupted!!!
...
UndefinedObject>>executeStatements (foo.st:7)

$ gst -I foo.img
GNU Smalltalk ready

st> stdin next
nothing even if the millisecond clock should pass nicely,


i will spend the next half an hour on it and maybe I find something...

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 09/21/2011 11:42 PM, Holger Hans Peter Freyther wrote:

Hi,

I am not sure about the right/nice semantic. Should (Delay forSeconds: 3)
wait, sleep three seconds of image time? of real time passed in the world? I
wouldn't mind if all timers fire... (famous last words).

So what appears to happen is:
        - (Delay forSeconds: 3) wait, will make the
          Delay>>#handleDelayRequestor call

          Processor signal: TimeoutSem atMilliseconds: nextTick
        -> VMpr_Processor_signalAtMillisecond
         -> _gst_async_timed_wait,
          -> _gst_async_interrupt_wait
          -> _gst_signal_after

What I guess:
        - We forget about this semaphore waiting for the VALARM to fire off,
          we don't store the _gst_sem_int_vec..


What I'm missing:
        - I still miss the code that puts the Process into sleep because it is
waiting for a semaphore, I kind of assume...

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 09/22/2011 12:25 AM, Holger Hans Peter Freyther wrote:

> What I guess:
> - We forget about this semaphore waiting for the VALARM to fire off,
>  we don't store the _gst_sem_int_vec..

the easiest way to get unstuck is:

Delay.TimeoutSem signal


probably combined with restoring the uptime could be quite nice. My current
'timer' code is using wall-clock time... i plan to update it to a monotonic
tick, it would be nice if Time millisecondsClockValue would be that.

holger

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 09/22/2011 12:55 AM, Holger Hans Peter Freyther wrote:
> Delay.TimeoutSem signal

Good, thanks.

> probably combined with restoring the uptime could be quite nice. My current
> 'timer' code is using wall-clock time... i plan to update it to a monotonic
> tick, it would be nice if Time millisecondsClockValue would be that.

millisecondsClockValue is monotonic, just not across image saves.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 09/22/2011 10:03 AM, Paolo Bonzini wrote:
Okay, how to move forward then:

a)

we keep track of alarms and we expire them on image resume? this will probably
require modifications to the image format? We use addDependent on Time to
save/restore the millisecondsClockValue?


b)

We just let each Delay expire after a image restoration? E.g. by a resume
handler that sets the expected millisecondsClockValue to 0 and then calls the
Delay.Timeout... signal handler...

different:
Looking at the code, it appears that Process signal: atMilliseconds can only
be used by one user on the VM?



_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 09/22/2011 10:12 AM, Holger Hans Peter Freyther wrote:
> Okay, how to move forward then:
>
> a)
>
> we keep track of alarms and we expire them on image resume? this will probably
> require modifications to the image format? We use addDependent on Time to
> save/restore the millisecondsClockValue?

No modifications to the image, try the attached patch.

> b)
>
> We just let each Delay expire after a image restoration?

I'm not sure I like this.  Let the Delays expire in due time.

> different:
> Looking at the code, it appears that Process signal: atMilliseconds can only
> be used by one user on the VM?

Yes, the delay process multiplexes it.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 09/22/2011 10:34 AM, Paolo Bonzini wrote:

> No modifications to the image, try the attached patch.

~/install/gst/bin/gst -i -f foo.st
1
3001
6001

ich@xiaoyu:~$ ~/install/gst/bin/gst -I foo.img
GNU Smalltalk ready

st> stdin next
3001
6002
9003
12003
15004
18004
21004
24005

hmm... does this indicate a problem/clock drift? probably not


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 09/22/2011 11:51 AM, Holger Hans Peter Freyther wrote:
It is drift, but it's expected.  With #forSeconds:/#forMilliseconds:,
the time to execute the #printNl sums up and causes drift.

If you use untilMilliseconds:, it will work correctly:

Eval [
         Time millisecondClockValue printNl.
         Smalltalk at: #FOO put: [|n| n:= 0.
         [(Delay untilMilliseconds: (n :=n+1)*3000) wait.
          Time millisecondClockValue printNl] repeat] fork.

         ObjectMemory snapshot: 'foo.img'.
         stdin next
]

$ gst -i -f foo.st
1
"Global garbage collection... done"
3001
6001
9002
12001
15001
18001
21002
24002
27001
$ ./gst -I foo.img
GNU Smalltalk ready

st> stdin next
3025
6001
9000
12001
15001
18000

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk