> 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: >> 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. 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: > > 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. Yes, there was a bug. :) Paolo _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
Free forum by Nabble | Edit this page |