Re: Sporadic process issue on Magritte tests

> On 15 Apr 2015, at 20:07, Holger Freyther <[hidden email]> wrote:
>
>
> it does hang from time to time :(. The first I wonder if we couldn’t change the way
> VMpr_Processor_signalAtNanosecondClockValue and family is implemented.
> Couldn’t we do the _gst_get_ns_time at a later stage? E.g. rename _gst_signal_at
> to _gst_signal_in and then deal with it there? I forgot why we still need to add the
> ClockOnStartupTime to the resumptionTime

I need to invest if that is scheduling, coalsceling or the cost of disarming, arming
the timer and the signal. but what I see is that

primitive:   arg2 1429121982628328000  now 1429121982628320000
signal_at:           1429121982628328000 now 1429121982628331000

If now > nsTime the deltaMilli will be a huge number and we will sleep a very
long time. My current preference would be to have a single _gst_get_ns_time
call to arm these timers and a single comparison.


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

On 15/04/2015 20:36, Holger Freyther wrote:
If now > nsTime, the deltaMilli should be made as small as possible.

The point of using absolute deadline is exactly to match deadlines as
close as possible ("perfect" if the syscall ultimately lets you specify
an absolute deadline).  Relative deadlines become less and less accurate
the more load you have, because you can be preempted away between the
computation of the deadline and the setting of the timer.

This is particularly relevant with cooperative multithreading such as
Smalltalk's.

Paolo

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

> On 16 Apr 2015, at 04:01, Paolo Bonzini <[hidden email]> wrote:
>


> The point of using absolute deadline is exactly to match deadlines as
> close as possible ("perfect" if the syscall ultimately lets you specify
> an absolute deadline).  Relative deadlines become less and less accurate
> the more load you have, because you can be preempted away between the
> computation of the deadline and the setting of the timer.
>
> This is particularly relevant with cooperative multithreading such as
> Smalltalk’s.

Okay but the current implementation appears to be improvable.

VMpr_Processor_signalAtNanosecondClockValue
  * Get current time and then check if to signal directly or queue
  _gst_async_timed_wait
   * Cancel the current alarm
   * Schedule waiting for the new SIGALRM
   * Call _gst_sigalrm_at
   _gst_sigalrm_at
      * I don’t know how linux behaves with TIMER_ABSTIME if it
        is in the past but apparently it does behave (hurray!)
      * Call _gst_get_ns_time
      * And check how many seconds to sleep

After going through the list it is only inefficient for the non
timer_settime case. So I withdraw my comment. :)

holger


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

On 16/04/2015 13:06, Holger Freyther wrote:
Yes, there was a bug. :)

Paolo

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