2 ms·

Good point, cancelling concurrent actions that started another concurrent actions is extremely complicated. I don't think humans can solve it efficiently in rea

• 01HNNWZ0MV43FF 3y ago
  I have some fun habits to "idiot-proof" things. If I'm paying for something with my credit card, I keep my wallet out until my card is back in it. If I'm cooking something on the stove, the kitchen light and the exhaust fan must be on. So at any moment, if my wallet is out, I know I must think about my card before I put my wallet back in my purse. And if the kitchen light is on or I hear the fan, I must check the stove regularly. I have a couple friends who constantly lose phones or wallets, and I simply don't. It's not intuitive to program but what's worked for me in software is, simply do _everything_ on every tick, and make sure the loop always ticks. Anything you can't do in tick, has to be made into an async task somehow and monitored every frame. Even up to a thousand tasks, "Is this still running? Should I stop it? Should I start it?" is a very cheap question to ask. I believe this is how some embedded folks code, like for a furnace controller. A lot of multi-threading and TOCTOU vulns also seem to come down to "What if just one thread of yours froze for 60 seconds between any two atomic operations?" If I do something like create a file and then set permissions on it, it feels like it's fast. But actually, an attacker only needs one time slice where the permissions are wrong to get in. Luckily I don't work in security, so I just do my best.