Feature Request: TIMERFD about source-x HOT 6 CLOSED

Honestly 1 decisecond is 100 milliseconds, so TIMERFMS ds*100 is same as TIMERFD just multiply the amount of Decisecond by 100 to make it timerfd, but if you still insist for a function;

[FUNCTION TIMERFD]
IF (<dARGV> < 2)
  TIMERFMS <ARGS> //Return default errors, if ARGS has 1 argument.
  RETURN 0
ENDIF
TIMERFMS <EVAL <STRTOKEN '<ARGS>', 1, ','> * 100>,<STRTOKEN '<ARGS>', 2-, ','>

from source-x.

The thing is not that its not possible to do otherwise, but everytime there is a topic about timerMS or timerfMS, most of the veterans suggest not using MS, because its supper heavy and hungry for sphere.

However thanks for alternative.

from source-x.

Technically using TIMERF TIMERFD or TIMERFMS has no difference, when you use TIMERF sphere tells that call me once in second*1000 milliseconds, so using TIMERFMS 1000 or TIMERF 1 doesn't have any difference, so yes I can add TIMERFD but it will do same thing with the one I gave you as a script, because I just gonna set the timeout same as the script.

You can see that the TIMERF multiplies the value you entered by 1000 to change to millisecond on;
Note: fSecond is a bool, which set to true if you use TIMERF instead of TIMERFMS

All code:

from source-x.

If you still think TIMERFD should exists, I could add it for just as symbolically, but honestly it will have no effect on performance at all.

from source-x.

Well Im not skilled enough to understand the code you posted, but from the explanation it makes sense. I was just wondering why we have been warned to not use the MS stuff, if its basically the same.
I'll use your function then, thanks.

from source-x.

TIMERD is there for historical purposes, i guess it won't harm to have TIMERFD for consistency, even if it's not so needed.
In any case, as said timerf used timerfms and multiplies the value. We might have said to avoid using timer(f)ms too often with too small delays to avoid overload, but timer(f)ms isn't bad per se

from source-x.