Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: sleep() function #156

Open
IvanVeloz opened this issue Jun 4, 2024 · 8 comments
Open

Feature request: sleep() function #156

IvanVeloz opened this issue Jun 4, 2024 · 8 comments
Labels
enhancement New feature or request

Comments

@IvanVeloz
Copy link
Contributor

To complement the growing set of POSIX functions, a sleep() and usleep() functions could be added to BlocksDS, making use of a hardware timer as a monotonic clock.

I understand using up timers this can interfere with some games, but it's so handy for applications (and since we have the monotonic clock, we can also implement a bunch of other time functions). In my opinion, it should be available by default under unistd.h, with an option to be disabled by something like #define NO_MONOTONIC.

@AntonioND AntonioND added the enhancement New feature or request label Jun 4, 2024
@AntonioND
Copy link
Member

It seems like a reasonable request. We already have some POSIX functions that work in a relatively special way. I guess the implementation could check if there is any free timer and use that one, or we could hardcode a timer, or even have a helper function that can switch the timer that is used.

I don't expect almost any game to use sleep() for anything, so I guess it doesn't have a big impact outside of helping port Linux applications to BlocksDS.

We would need to document the final behaviour of the function too.

I'm open to suggestions.

@asiekierka
Copy link
Contributor

I think this should wait until at least one broader thing is considered: a system for allocating and freeing hardware resources like timers, DMA, etc., that homebrew in general can be encouraged to use, so we don't fall into conflicts.

@IvanVeloz
Copy link
Contributor Author

I think this should wait until at least one broader thing is considered: a system for allocating and freeing hardware resources like timers, DMA, etc., that homebrew in general can be encouraged to use, so we don't fall into conflicts.

Similar to bgInit_call()?

Working with ports of libraries (LVGL, lwip and others) I've noticed they want callbacks for a tick or millisecond counter, to use as a monotonic clock. This is a very common feature to have (Linux has clock_gettime(), Arduino has millis()).

My suggestion would be a system similar to the background APIs (like the syscall [bgInit_call()]) to manage timers in general, as you say. That is an API that needs to be decided on.

Another function could be made available to enable the monotonic timer systemwide. The POSIX API in particular can handle a clock not existing. It's also nice because it can get the real time clock and we already use POSIX APIs elsewhere (sockets, files). So perhaps this API doesn't need to be designed from scratch.

I can work on this feature if you'd like, after the API things are decided on.

@asiekierka
Copy link
Contributor

Really, at that point we should consider morphing the coroutine system into some kind of RTOS - but I don't have the necessary field experience to start that conversation.

@IvanVeloz
Copy link
Contributor Author

I see what you mean. I don't have that experience writing OSes either. I think in the meantime I'm going to write it as an external library with the POSIX API. That way the source code is available if we ever get there.

@AntonioND
Copy link
Member

Yes, I think that you having your own implementation of sleep() is the best idea for now.

@IvanVeloz
Copy link
Contributor Author

Sounds good! I'm closing the feature request as "not planned".

@IvanVeloz IvanVeloz closed this as not planned Won't fix, can't repro, duplicate, stale Nov 6, 2024
@asiekierka asiekierka reopened this Nov 7, 2024
@asiekierka
Copy link
Contributor

That is appreciated, but we still want to get around to this at some point; just not soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants