> On 15 Apr 2015, at 20:07, Holger Freyther <[email protected]> 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 [email protected] https://lists.gnu.org/mailman/listinfo/help-smalltalk
