search

opendlang / opend

Boost Software License 1.0
76 stars 17 forks source link

Add druntime Timer #63

Closed IgorDeepakM closed 3 months ago

IgorDeepakM commented 3 months ago

This is an attempt to create an OS independent timer API in druntime. Nothing is set in stone with the PR and it is open for modifications in order make it better.

On Linux/Posix, the usual timer_create/timer_settime is used. I opted for an internal timer queue so far but it is also possible to create a new time timer_create and SIGEV_THREAD. Even if it is supposed to per process timer, the C library usually allows 1000 or so timers to be created.

On Windows, the only timer I could find with ok accuracy is CreateWaitableTimerEx with the CREATE_WAITABLE_TIMER_HIGH_RESOLUTION flag. TimeBeginPeriod(1) didn't work on my system and I'm not that keen on a system wide change. CREATE_WAITABLE_TIMER_HIGH_RESOLUTION is pretty recent addition and I don't know what happens when you try this out on an earlier Windows like Windows 7.

Another thing I'm not sure satisfied is how you must expose all the source files when you compile your program with druntime. Is there a better way to limit what the program can "see".

Unfortunately I'm not able to implement the timer for MacOS even if I would like to. I have left the MacOS implementation in a unimplemented stub status. If anyone wants to implement, it would be great.

adamdruppe commented 3 months ago

What would you use this for?

IgorDeepakM commented 3 months ago

For programs that needs a timer so that they don't need to reimplement a timer each timer. This is similar to C# threading.timer.

adamdruppe commented 3 months ago

timer_create is just kinda terrible and i wouldn't use it for much of anything irl.

IgorDeepakM commented 3 months ago

timer_create is just kinda terrible and i wouldn't use it for much of anything irl.

POSIX timer in Linux isn't that bad when it comes to accuracy. I'm not sure if there is any better.

Since there is a thread in a loop, there is the possibility to use usleep or simiar but I'm not sure if it is better. However, I'm not sure how that will work with a timer that you can cancel.

If you have any better timer, I'm open for suggestions.

adamdruppe commented 3 months ago

Accuracy is a bad thing in a lot of applications, that's why Windows has the options it has. It'd be fairly important for an api to expose this requirement somehow too.

But I'm more thinking about using it. The posix thing calls a signal handler which severely limits its utility. The other option to call it from another thread is similarly problematic.

I'd much rather bless an event loop.

IgorDeepakM commented 3 months ago

Accuracy is a bad thing in a lot of applications, that's why Windows has the options it has. It'd be fairly important for an api to expose this requirement somehow too.

I think you are referring to controlling the accuracy of the timers. Some timer OS interfaces has an accuracy parameters as well, this in order to be able to merge timeouts so that waking up the system from power save can be done more seldom. It is possible that such an accuracy parameter can be added to the timer interface. What the accuracy parameter really mean must also be defined.

I'd much rather bless an event loop.

I don't know what this event loop is. I have to be presented with a design in order to understand what it is supposed to do.