--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/f835ffd8-8eaf-4bad-a683-ae8354ee3231o%40googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to va-sma...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/f835ffd8-8eaf-4bad-a683-ae8354ee3231o%40googlegroups.com.
I just observed 100% CPU usage with something like '[(Delay forSeconds: 5) wait] repeat' under Linux. Using AbtTimedWait works fine.
Cheers,Adriaan.
--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/c9f8c97c-7f5b-409f-85f6-3b76d457063do%40googlegroups.com.
Ah, forget all I wrote. The actual code was missing the 'wait'.... :-s
So... you shouldn't use Delay with a value less then 100ms. What will happen if you do it anyway?
I noticed that, for instance AbtEwHoverHelpManager>>#backgroundRunDelay is using a shorter delay and SciDispatcher>>#callLoopingRecvWith:with:with:with: potentially too. Does that mean those methods are a little bit broken?
The one in SciDispatcher also has an interesting feat: it does just a yield when the delay is shorter than 16ms. Would having a 'smart' delay that just yields for short delays be a good idea? And would that be useful for Delay and not so much for AbtTimedWait?Any thoughts?
| |||||||||||||||||
Hi Mariano,Thanks for your answer. That is what we see indeed at places where we use Delay with less then 100ms: unexpected longer delays that even look like a hangups. We're looking at using AbtTimedWait for those.
As for the 'smart' delay, I'm not sure I was clear enough, but I didn't mean to have multiple yields for a single short delay. Just one yield as a very short delay. I understand that the threshold for doing a yield vs a real delay would have to be arbitrary.
Hi Everyone,Delay is one of my favorite topics. I studied it awhile ago, learned a lot and hopefully remember most of it.First, it should be known that the 100 ms interval is NOT fixed and can be changed with:Delay interruptPeriod: 16.It is a private method but if you want a smaller interrupt period, it is probably worth the risk.It is the value used to set the hardware timer interrupt.My old tests showed that the smallest value that would result in short delays was 14 ms. I haven't tested lately but I think 16 ms is about as low a one can go based upon Windows 10 changes see: https://randomascii.wordpress.com/2020/10/04/windows-timer-resolution-the-great-rule-change/ for more details.
Hi Seth,Thanks. Okay, I should have looked a little closer at #EsTimedWait and its #useThreadMethod method. What happens to the fork that the PlatformFunction was called. Doesn't its process end up in the Delay list as not ready (or not in the list, I forget)? I guess it will become ready when the PlatformFunction returns but will Delay be able to dispatch it right away or will it be waiting on the last 100 ms timer?I agree with you about setting the interrupt period to less than 100 ms but developers shouldn't be setting short delays if they don't really want them and are willing to pay the price. Changing the interrupt period gives them the short delays.Now, I don't really like setting the interrupt period to less than 100 ms. I have seldom found it useful and have changed code to get the value as a setting, just incase it might help.
Hi Richard,This is true, but we noticed an impact on devices like RasPi which is why it was brought up.There is a high-priority timer thread that is constantly running in the background that fires at Delay intervals and sends messages through the async queue.So, as you approach 0 on the delay, you are hammering the async queue harder and harder.
But as I think is in the spirit of what you are saying....going from 100ms to 50ms is probably not really a big deal. Its as you approach the lower bounds you may be inadvertently impactingother parts of the program by keeping the async queue fuller. This impact on Linux may be more noticeable than on Windows based on how the UI works between the 2.
--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/491a1220-2f70-44a1-9a27-2dfd393df898n%40googlegroups.com.
forSeconds: aNumber
"Cause the current process to wait for a
number of seconds; do not return until the interval is up.
Arguments:
aNumber - <Number> number of seconds to wait"
^self forMilliseconds: (aNumber * 1000)
---
forMilliseconds: aNumber
"Cause the current process to wait for a
number of milliseconds; do not return until the interval is up.
Arguments:
aNumber - <Number> number of milliseconds to wait"
^self new
waitInterval: aNumber asInteger;
wait