So… got any more comedy for me to look at? 👇 Also don’t forget you can try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/TheCherno . You’ll also get 20% off an annual premium subscription.

I am a Python programmer and this is how I would solve it: import os import sys import time # All done, Python takes 5 minutes to start

Remember: this is the stuff we’re training our AI on

Trolling is a art; Topnik1 is a true artist.

As a firmware engineer, my first instinct was "set the alarm peripheral to trigger an interrupt handler"

Funny. I am an office application engineer and my first thought at looking at your code was "noooooo!!!" We try to use as little resources as possible and a 5ms constant loop is "terrible" for battery life. It's funny how people from different coding worlds approach a problem different. My first instinct was much closer to the sleep/wait implementation (though I wouldn't waste an entire thread just to wait).

sleep doesn't take any cpu resources during the sleep time since the thread will be put into the pending queue (on most OS). Periodically checking will consume CPU time, even if it is minimal, and is a very Game Engine like solution.

You want your users to hate you? Tell the user in the console to set a timer for 5 minutes, wait for them to press space and start the timer, and press space to finish it. :)

I'd never think i would ever spend 20 minutes to watch a 11 year old post about a 5 minute timer. but i learned something Edit: 350 likes??? Damn i must be famous

Good video overall, but the part about precision at 15:21 is a bit lacking. To be honest, precision is most likely not very important when sleeping for 5 minutes, but the overall takeaway of how sleep work is a bit wrong. Sleep will sleep for *AT LEAST* the time specified, but could sleep for quite a bit longer depending on other task's CPU utilization, the HPET (Hardware Precision Event Timer) used by the system (or not, on some system there might not even be one), the OS's timer resolution settings, the virtual timer resolution thing that windows do on laptops for powersaving where it will actually stretch the resolution, etc etc... Therefore, when very high precision is desired (for example, a frame limiter in a game, to have smooth frame pacing), you don't want to sleep all the way, but rather, sleep for a significant portion of the time, but busy-loop at the end. This fundamental misunderstanding of how sleeping work is why so many games have built-in frame limiters with absolutely garbage frame-pacing, and that you get a much smoother experience by disabling it and using something like RTSS's frame limiter instead.

I am not trying to protect topnik1's code in the video, it is pretty bad indeed BUT I am pretty sure it is not going to be 300 stack frames deep. From the looks of it, it is a tail recursive function, so any major compiler (e.g. clang) will do tail call optimization.

In embedded land we have real timers! Talk about accurate... sub-nanosecond is easily doable. Overhead? It's a peripheral! Ignore it until it interrupts you.... or have it actually trigger an output without bothering you if you really need that accuracy. Love timers.

"Train the AI using the entire internet, it will contain all of human knowledge." The AI: "derp, but with extraordinary confidence"

I'm surprised no one brought up interrupts, I don't know about modern C++, but I've seen in old school assembly this concept of setting a "flag" that interrupts execution and calls/executes a function before handing back the CPU.

A game-developer who cautions to not use OS-dependent libraries. Music in my Linux-gaming ears. 😉

I recently made a discord bot. The task was giving every user a cooldown timer. Well at first glance it may seem like an insane task but once you realise time just goes on you don't have to do any computation meanwhile. You can just compare start and end whenever user needs to be updated. And this is how many village/base building games use on their playerbase. Like for example you need a buliding that takes 3 days to bulids. When the player is online you can just update every second but when the player is offline you can have the end date and compare to that when the player logs in again. Or someone interacts with that user.

... And then you notice that your 5sec timer needs 5.03sec on your first PC. On the second it takes 5.1s and after some debugging you find out the OS moved the thread onto an E core and that your thread priority was not high enough. Would be nice to extend this video to handle more details. Like higher+highest accuracy or lower+lowest CPU usage.

Fork Execve bash -c sleep 5

This threaded timer has subtle bug. If 'work' performed during the timer duration takes longer than the timer itself then after the timer concludes its scheduled work will need to wait for the 'join' thus delaying the execution by more than the 5 minutes. On the flip side - moving the 'timer' callback to the timer thread will require work of main and 'timer' to be concurrent which brings its own set of problems. Frankly - having any sort of 'delayed' execution done in a single thread whil stuff is happening during the wait period is a pretty difficult problem to tackle. Unless it is something like a game, where there is a game loop or an event driven application. But even then, depending on resolution of the loop the wait period might be very, very different to what was specified.

at first glance I totally didn't read "using namespace std::cherno_literals;"

The best solution for this is asynchronous execution. That way you can decide how the execution is performed i.e on the same thread or on a separate thread, and when the execution / timer is complete, you can decide if you want to rejoin the execution context (thread) back to main and take the perf hit, or run your logic on the background thread without any perf hit. You get all the benefits i.e you don't need to worry about thread safety and its fully configurable in how you want it to run.

17:15 Btw, small nitpick for the C++14 users (and above): move your callback into the lambda capture, because if the callback is an object with a defined operator() (like a lambda), there could be big-ish members (like with a lambda capture).

9:21 for that case tail call elimination should fire unless there were stack allocations done in "dowhatuwantinmeantime". So it effectively turns into jump to beginning of function.

Yeah def getting into thread pool territory. Would love to see more on this.

My way would include obtaining a timestamp at the beginning, checking every iteration of the application loop whether the time elapsed is greater than or equals the start time, then doing whatever if said condition was true

As an embedded developer I like to use SIGALRM and handler in case I'm sure that I'll need to have one timer only at the same time. If I need to have several timers I use timer_create aka Linux timers.

Your analysis and explanation were very helpful.

I think this is one of the best situations where Asio (also packaged in Boost) actually makes sense if you are planning to do this kind of thing multiple times in a project. If you have to run multiple callbacks on a repeating and variable timer, and you have to handle IO in general, slapping an Asio io_context and a few steady timers is super easy and extremely reliable. You also get nice functionality like early cancelation, error code checking and other things that make it nice for production.

As an embedded engineer, I would just use a built-in timer interrupt, which should be available for all platforms, although not portable.

I remember when I was first starting programming I learned visual basic script (Why I chose that I have no idea), and I was looking up how to wait for a period of time and ended up on a forum that said the way to set a timer was to ping google, figure out how long that took, and then divide the time you want to wait by the length of the ping and ping google that amount of times.

love this kind of content almost as much as your other content, be it hazel coding reviews and more

Condition signals is probably something you want with huge delays like that. Especially if you want to exit cleanly without waiting forever

We had to run code in 'real-time' in the sense of training simulators. This means we had to perform a lot of calculations, then do I/O interfacing with the student's control panels in a way that the student couldn't tell the difference between the simulator and the actual control room. So update the I/O with new calculation results at LEAST every 250 ms. I know sounds slow by gaming standards, but we did a LOT of physics calculations for an entire power plant. So we set up what had to be done in each 'frame' and used a repeating interrupt timer configuration. A frame ran doing calcs and I/O then sleeps until the next interrupt. If we occasionally 'miss' an interrupt because the calcs took too long, we had to 'catch up' the next frame. (one way to do this was the interrupt service routine increment a simple frame_counter and main loop checks if we 'missed' an incremental step) For time delays, we simply did a counter in the main code that would count up to 'x' value because we knew each time the code executed it was 'delta-time' step since last execution. So for 5 minutes at a frame time of 250 ms, simply count up to 1200. This was a few years back, but you can see it's similar to your 'game engine' concept.

25 years ago when I started coding I took setTimeout and setInterval in ActionScript for granted, I was 8. Now I was thinking of a thread with a loop and events that trigger callbacks as other threads depending on timers you set that would mimick that behaviour but when you mentioned Promises I realized it would be way easier to open a thread for each timer and just sleep...

Just shows that nothing is simple. What type of app are you working with? Do you need the thread to remain alive while the timer is running? Do you care about multi-platform? How much accuracy do you need? How important is it that code have low processing overhead? And the list goes on. (And that recursive example is going to keep me awake tonight, it takes a special type of person to write code like that)

For the first idea example you showed I would have just calculated now + 5 mins when the timer is created, store that time as target time. Check in loop if current time is greater or equal to the target time, if so, the timer has triggered. Rather than casting a duration of one time minus the other each loop.

Great video. You should do more videos like this where you are looking at fundamental things like timers etc. The video was funny in relation to the code suggestions in the forum but also educational when you explained them and presented your professional solution.

I was thinking about the "busy wait" issue you end up with in game loops, especially if you need to serialize timers / handle game saves when the user quits, and I came up with, storing all your deferred functions in a heap/priority queue, and then just check the head of the queue, and sleep for that amount of time, if you have a DSL, you could potentially have your code look like "bad" code that just calls sleep(), but really it's just a co-routine that yields the CPU.

Wow your first Video on multithreading and you introduced async, threads, sleep and context. I was actually looking for a video on the topic of multithreading this morning - couldn't find one and now here it is, just a little bit more complex ^^

19:34 If I wanted it to happen on the main thread, I'd probably have a game loop (as you showed) but with an integrated event system. This would be implemented as a min-heap with the time it should be called at as the value being sorted on. Then all timers could be checked with a single comparison. (If the lowest time has not been reached, all the others are guaranteed not to have been reached.) At this point though, we are very close to a full game engine core haha

generally the extensible way is to maintain a priority queue that contains time values and callbacks. Every loop poll the first element of the priority queue and remove until the time value > current time. That way you can have as many timers as you like. Things get way more complex if you need accurate sleep without spinning though. You pretty much need to get into platform-specific api as well as setting certain thread priority/interrupt rate. Recent windows has pretty weird and relatively undocumented timer handling.

Шел Черно по интернету, увидел форум, заглянул в него и сгорел.

This is such a great video topic!

Yeah people can really think in too simple ways about such a thing, but that forum thread was really bad. LOL. As someone with experience for many years in several programming languages, especially including C# professionally and but for example also Rust nowadays (and it is my favorite now), I can only say, that this modern type of Async code at the end of the video was obviously the solution I was thinking about immediately, even though I didn't exactly know the modern C++ implementation for async code. But this is how in modern programming this kind of thing is generally done. Many languages do very similar things. All these things are also a related to having programming experience here. If you have done enough concurrent and parallel programming, then it gradually becomes far more natural to think that way.

I’ve actually learnt so much from this channel. Since There’s not a single good explanation of inline functions anywhere on KZfaq could you please cover that in your next video? Or sometime in the future

TBH I really don't like all those "sleep"-based solutions, which (1) consume an entire thread just to have it do nothing, and (2) make the actual waited time depend on when the kernel decides to schedule the thread after the sleep runs out, depending on CPU load at the time etc. (at a scale of 5 minutes that's not very important, but still, it's a fundamentally inaccurate approach) To be fair to the people who suggested it, C++ doesn't really give us the tools to actually build a timer. (but windows does, so I guess we're back to #include after all)

haven't watched for even 1 second, but, the answer is a thread that sleeps for nearly 5m, then a few ms until the time is reached, then calls a callback or sets a flag. when I was making my scratch gui system in c++ I had to solve the timer issue so I wrote a whole scheduler and event handler subsystem.

This is a great video 👏 I vote Yes for more videos of this format

The 300 stack frames comment on the recursive function... there is a thing called tail call optimization, which apparently C++ compilers have been doing a while, that optimizes this into a loop. There is quite a few people that think more in recursion than in iteration, especially in a functional context. the async vs thread thing is nitpicking for the sake of it. there is really no advantage to be had _here_ by using async instead of just directly spawning a thread. you don't gain control, you don't gain performance, you are just obscuring the fact that a thread is spawned and suspended by wrapping it up in async. And when this async stuff get's put into a context where this might be scheduled into a thread pool, now you have a thread from the pool blocked for 5 minutes. From game engines you are probably used to cooperative multi tasking, which could have been an interesting spin and the one solution being bashed from the forum actually describes the idea of cooperative multi tasking, albeit with some problems.

Inexperienced people writing funny code - my favourite form of entertainment :D

note that doing what you did with the system_clock or high_resolution_clock (in case it's not steady) instead of steady_clock can work most of the time, but you'll get issues when the time changes due to daylight savings or such, and you can accidentally get a one hour and 5 min timer

Very practical example in real world application!!

I've made a c++ scheduler class, it's kinda like your example and is reusable. basically it takes length of time and a pointer to a function. It uses async and I can schedule an action to happen on a timer later on. I have a timed game that uses it to call gameover() when the time is up. My test said "Hello World" a few times the "Goodbye World"

It's interesting I never thought about how involved the simple question "how to delay code execution by X time" actually is. I usually work on stuff that is IO heavy and focuses on processing events as they come in (ie: a button was pressed, a socket received data, a cable was connected, ...). More often than not I already have an event loop, for example based on file handles and epoll/select. So my first instinct for a non-blocking timer was: create a timerfd and put it into the existing event loop. This video made me realize that I've never considered how many things become more straightforward if you're running a simulation that has one thread continuously running anyway.

You can put your timer-finished code inside the if (status == ready) block or after the loop and then your timer class is responsible for fewer things

Mr. Yan could you give us a homework to do for the next episode of the game engine series? Thanks for all your lovely content ❤❤❤

never knew (nor did i think to check) if async and promises exist in c++ after using them in JS. Awesome

Linux has some nice set of timers functionality via createtimer/ settimer / deletetimer. The timer delivery is via real time signals which can be a bit tricky to get right though.

A single-threaded task scheduler would be a cool video idea!

Timing in CS is an artform, basically an optimization between precision and CPU usage. The best approach is to go with the lowest level hardware interrupts and register a callback on the interrupt event. In higher level code the more precise timing you want, more frequently you need to schedule your timer thread which will lead to higher CPU usage. If you optimize to have lower CPU usage, the thread will be scheduled less often, therefore decreasing precision (the thread won't be able to check for elapsed time as frequently). Considering this the == approach in one of the replies is a huge mistake, because it is guaranteed that the timer never will be exactly equal due to the operating system's added thread scheduling overhead. Even with hardware interrupts there will be a thread swap operation losing some time until the instruction pointer is set to the callback method. Good stuff

I had a nice time with this video.

That's a nice video! And what I like the most and that you seem to be one of the very few people I know, who actually use the steady_clock for timers and stopwatches, which is by the way the intended application of this tool. The vast majority resorts to high_resolution clock and then go around in panic when their system time gets updated. And man, is it a pain to search for a root of such a bug because it's really hard to reproduce it on your own machine and the behaviour just seems random. By the way, any implementation of sleep only guarantees that you sleep for at least a timespan or at least until the point in time. There is actually no upper limit on how much time would pass after that PS I guess the so-called expert wanted to do something similar to the main loop concept with a step of second instead of display frequency but just messed this up so badly that ended up with recursive calls. As for your point in the video, I saw a lot of samples of custom games where the time for actually running your game was just completely forgotten in your wait function at the end of the loop.

sleep() is great untill you realize you can't cancel your timer and notify the user about it right away, so if you do need to handle cancellations (either manual or due to the process' shutdown), you're screwed. So: * If you want a delay in the current thread just use condition_variable::wait_for. * If you want it to be executed asynchronously, either spawn a thread yourself or spawn an std::async task (which may very well spawn a thread under the hood anyway) and, again, wait on a condvar. * If you want your solution to be generic and scalable, you're bound to end up with some kind of scheduler, so you either use a library like boost asio (whose timers do use a scheduler under the hood), or write one yourself. As "simple" as that. Frankly, seeing how easy it is to do the same thing in other languages like C#, coming back to C++ is just painful.

If you need to wait in performance critical multi threaded environment for an accurate amount of time as shortly mentioned in the video keep in mind sleep functions are not accurate (I would assume async can not fix this). with more threads that cpu cores the time sleep oversleeps tends to go up too. for full accuracy empty loops are the only way I know, for something reasonable reduce the sleep time with an empty loop afterwards. When I had problems with this I split the sleep into multiple calls (I felt like shorter sleeps are more accurate). I used something like this (C): void my_sleep_fast(const int64_t target_t) { int64_t time_diff; int64_t temp_sleep; time_diff = target_t - get_microseconds_time(); temp_sleep = time_diff - (time_diff >> 3); while (temp_sleep > SLEEP_TOLERANCE_FAST) { usleep(temp_sleep); time_diff = target_t - get_microseconds_time(); temp_sleep = time_diff - (time_diff >> 3); } usleep(SLEEP_TOLERANCE_FAST); }

Coming from POSIX land, where anything interesting has a pollfd (file-descriptor) at the bottom of it, event loops consist of something that gathers all the interesting events and then calling "poll" on their pollfd's (or calling "epoll" or "select"). So, in that world, a timer like this is either implemented via a timerfd (you tell the kernel to create a "file" and trigger it at a specific time) or by simply setting the timeout for the poll call to the earliest wake-up time among your active timers (personally, I prefer that, gives more control). No messing around with threads. Coroutines are another way to do the same thing (coroutines are syntactic sugar on top of the same mechanisms).

Interesting hearing your take Doing embedded C mainly I first think if i have a real time clock or not And would want to setup an interrupt on it to count up

There is another case you didn't exactly mention. I've often designed my programs around event loops (I started writing programs before multiple cores were common). In that case, you need to have a timer expiry heap as part of your event loop so the loop can easily determine if you should just wait forever for an event, or wait until a specific time.

This really makes me appreciate the convenience of QTimer::singleShot(Duration msec, Functor &&functor). Implementing the event loop manually is such a pain.

I think the questions I'd like to see answered here are not 'how to do it in c++', but rather, how does the computer clock work. How do you call it? How do you keep it counting while doing other stuff? The library I'll end up using isn't the most important. Though I guess if you need to solve this very specific problem it's time consuming to take that step back.

20:00 My use cases of timers usually involve programming the interrupt controller, setting up HW timers or RTC alarms in microcontrollers... setting up "sleep"/standby/poweroff states What different worlds we live in :)

I code more than a decade in gta3script (the proprietary script language that Rockstar Games uses from GTA 2 to GTA V, maybe GTA VI too), and is just this: SCRIPT_START { WHILE timera < 300000 WAIT 0 ENDWHILE PRINT_STRING_NOW "ok" 1000 } SCRIPT_END Or just WAIT 300000 but would be basically a Sleep. PRINT_STRING_NOW would be PRINT_NOW (for translation support), but I'm using the modding variant for this example. The "NOW" is high priority, doesn't matter. Another detail, old GTAs like GTA SA have a bug and need to set NOP or some other command in the start of the script before any WHILE. But I like how big game companies simplified this.

std::thread::sleep_for(std::chrono::minutes(5))

This reminded me of a similar problem in robotics. A lot of people get burned by using Sleep or something similar, because your robot stops getting sensor data while it waits.

the while loop approach only works if you want to do something repeatedly. If you really want to do only one thing you need a thread obviously.

I'm working on a web project that has a rhythm game demo feature. There's a lot of time sensitive information here, and I was really surprised how much execution time plays a role, maybe not in first 10 seconds, but after a minute and a half definitely. In the end I rewrote the whole portion and painstakingly added time corrections based on current time and the timestamp of when Play was pressed on all elements.. What I see here too is that in most cases, the result might be around the requested 5min, but there'd definitely be drift overtime in more time sensitive cases like mine.

Actually very curious about what you find as a good solution for function timing, been curious what low performance-impact options there are

Timers are easy especially for hardware with different CPUs and MCUs. Some have even their own libraries for this, others you can setup a function to do this. It really depends what type of timer you need flr what. Most important thing is not to block other code that suppose to run in the "background" while the timer runs.

1:16 THANK YOU!

Nitpick: You could make the callback signature a template parameter so you can have type-safety at compile time.

std::this_thread::sleep_for() does not use a monotic clock by default. That is, if you change your system time, it affects the timer (at least on Windows).

But the one downside to your method, as opposed to a multithreaded solution with sleep(), is that you might run into an issue with timezones. The best scenario would seem to me to be a loop (multithreaded or single-threaded) that uses a chrono::duration object to measure 5 minutes directly.

How applications with subscription set the free trial timer and even if you have no internet connection and change the time of your pc or shutdown for days, the program will still calculate the time correctly and end the free trial at the specific time 🤔?

Are you going to post this code onto that forum post with some explanation or link to this video? Why or why not? Edit: Nevermind. The forum post is locked. That's a great reason NOT to. You don't ever see the code at the end of the TimerAsync function. I THINK this is what it should be: std::future TimerAsync(std::chrono::duration duration, std::function callback) I'm not 100% sure but I have written the code exactly as TheCherno has it except I use "using namespace std;" as well because i'm a rebel. So apart from the portion that can't be seen, I have written the code exactly as it is and it appears (oh, and I named Period to TimePeriod) to run and work the same. So, fairly sure my guess is correct.

13:56 forgive me if I'm wrong but the problem I see with the code here is that if the other process you run apart from the timer needs to finish every time before you check the time again you'll almost certainly not land on 5 minutes either. What if the process you run takes 10 minutes itself? Surely on an additional thread that example would be fine but in the code at 13:56 it would be 10 minutes before the timer would complete

15:20 Heavily depends on the OS scheduler. Some are more accurate than others (and some OS have multiple OS schedulers the user can choose from).

When I was at university in 2006, I had a lab about a timer, I don't remember exactly how I solved it, but the computer has a built-in timer that runs 18.2 times per second, I remember that I wrote this program in C with some assembly language inlining, which actually copied an interrupt from a certain port, then replaced it with my interrupt, my interrupt was executed 18.2 times per second and in it I made a decryption of the timer that the user entered, and when the timer was completed, I sent a certain byte to port 61h, but I may be wrong, to cause the speaker on the motherboard to beep, which signaled that the timer was over, then I replaced my interrupt with the one I copied earlier, and I used C only so that the user could enter the timer and display a successful message after it was completed, that's the story)

If you only have a few timers then the best way, assuming that cross platform is considered better than platform specific, would be to take the current time, add the timer amount and use that as the end trigger for that timer. Then it's a simple matter of checking in the main loop whether you've reached the target time or beyond. That's basically the way a coroutine would work too, if we're talking about the original working method and not the unholy hidden thread garbage that is usually used for async code these days. One of the things I love which they added with C++11 was UDL's. So adding 5min to a time is pretty easy and downright enjoyable now. I just wish they'd add that to C, especially since they added constexpr with C23.

Does the std lib have anything like the millis() function within the arduino IDE? I used to create non obstructive timers like this: Event to trigger timer sets variable = to millis() If(event) { Time = millis(); } If(currentTime-Time >= delayDuration){ Code to execute } Sorry if youre unfamiliar but millis() is a native function to arduino that counts up in milliseconds from the instant the MCU boots. The timing source is completely separate from the CPU and runs in the background and doesn't influence code execution(at least noticeably)

Oddly enough, my first experience working with threads(Java) for work was fixing a timer for an api just checking if a remote service is alive Lets just say the person who implemented the timer never thought about how the thread would stop Logs had 10K lines waiting for check to be complete and said the service was down because it kept doing the check. It was supposed to stop after 10 tries

I don't code in C++, mostly do powershell scripting, but when I saw this I though of a simple while loop like your final solution with a running timer. Though I'm interested why you used 'While (true)' instead of 'while (satus == std::future_status::ready)'. I will say timing code is always an interesting challenge with far deep rabbit holes at least in the languages I've played with, usually in-built function have some noticeable overhead.

I don't have crazy game engine, but I too think of everything in the context of a main loop. I think game programming just lives in every facet in everything that I code.

I know I've done a similar thing using Boost (boost::asio::deadline_timer() and then used boost::posix_time::seconds() to get the timer value), and that had worked for me, plus kept it asynchronous so it wouldn't hold up the rest of the system. (Of course part of that was having to use c++0x, I'm sure there's a better way to do it, but had to work with what I had)

For just basic timing a function/scope I wrote a little class that wrapped chrono, takes a timestamp on construct and prints the diff on destruct. Good enough for dead basic use cases, not something I would use in a larger / more serious project though.

I have a different timer use-case I'm not sure the best way to overcome. My game is like a drone racing game (space drones though) and I really want a flight replay recorder. I have one ,, but its built in (unity c#) to the regular update function, which means that although there is a vsync target which I've set to once per vsync frame (so for my cheap tv monitor , it works well because the game runs at a constant 60fps) ,,, it is very possible for the replay to run at a different and even inconsistent speed than the actual gameplay. I've tried some different things to make the replay be recorded at a more constant rate ,, but nothing results in smooth replay frames. If anything other than the visible frame generation is replayed, the replay is jumpy. Some people say just record player inputs ,, but I can't imagine this going well for my situation, especially if the scene is pushing the players computer, because there is so much interpolation going on with the physics objects. The one time it would be most important, is where I have a spin-gravity drum that is interpolating to create spin-gravity for the player to interact with ,, and the replay can run slow,, but at this point the entire scene is interpolating which would unquestionably result in a replay that has the player somewhere different than the recorded flight. I thought maybe my recorded frame could include a timestamp somehow, and then check itself, but as a newb that is probably just a bit harder than I have set down to attempt, mostly because I can't imagine how it will NOT be just as jumpy as trying to do something like run the replay recorder in the fixed update. Doing a bit of research ,, flight recorders appear to be not that terribly common, probably for the same reason. It is extremely critical that the flight replays exactly (like, a drone race) , and smoothly ,, so the only thing that I can imagine that will go well,, is if the game is lite enough that the computer can reach a fixed frame target without fail, both during recording and replaying. ,,, but ,, unity uses vsync as the recommended way to fix frame targets on desktop pc and recommends against setting a frame target bc of varying hardware ,, so although that should be fair with a 60fps budget tv,, a gaming monitor probably will vary more in resulting framerate as it produces enough frames to potentially max out the cpu. In other words,, for the most part, the flight recorder works great on my end!!!

I love embedded because there I have direct access to the cpu's timers/counters and interrupts ;)

futures can’t destruct with a running thread, usually there’s no need to check for the status with the purpose of ‘make sure it doesn’t get destroyed before the thread finishes’ 17:35

Great video.. You should go ahead and add your solution now on the post so that people can see it and understand how to write better code

Coming from a C background I would actually use an alarm :) Sort of like this: #include #include void handler(int s) { /* Whatever you want */ } int main(void) { struct sigaction sa; sa.sa_handler = handler; sigemptyset(&sa.sa_mask); sa.sa_flags = 0; sigaction(SIGALRM, &sa, NULL); /* Set up the alarm for 5 minutes... */ alarm(5*60); /* Rest of your code... */ } This way, your code (the process executing it) will be interrupted 5 minutes after the alarm() call was made. You can keep doing work until then. When the interruption comes (from a SIGALRM signal) your code will execute the handler function.

15:25 I think if your sleep library call supports 5 microsecond sleep time, it's just incorrectly implemented if it cannot accomplish it. On Linux, the sleep functionality that accepts shorter time periods than full second do support any length sleeps. However, very short sleeps are implemented as busy sleep where CPU keeps running at 100% and polls the current time until the exact correct amount of time has elapsed. This obviously doesn't end up being accurate if you have more threads than physical CPU cores because then OS has to do time multiplexing to run all the tasks and your OS is not going to schedule multiple processes running at 100% withing 5 microseconds because the task switching overhead in the CPU would kill nearly all the progress.

If you have a task manager, you get timers basically for free, I would think. And you have manual control over multithreading. You could have a specific list for delayed tasks, so you can have it ordered by execution time points, so you can avoid cycling through the whole list everytime you upate the timers.