Unity's "quirk" messed me up again. This time, I wanted the time when the key was pressed as precisely as possible, independent of the framerate.
So I put the input reading routine into the thread pool, which causes the first few readings to throw null reference exceptions. No biggie; the system needs a few moments to warm up. So, I try-catch that part.

But when I build the game, as soon as I reach the part where the game tries to read the input value, it hard-crashes before try-catch can act 🤦

Not really a surprise. Unity makes it abundantly clear that the Unity API may only be accessed from the main thread and doing otherwise it's undefined behaviour.

Can you elaborate on why do you need something like that? What is your use case? Are you trying to calculate reaction time? Just curious.

Save the data from the key detection thread into a data structure the main thread checks multiple times per frame (may cause performance drop due to branch predictors misses tho), effectively increasing your input sampling rate (still not frame independent but better than nothing).

Alternatively find some areas that are unoptimized or bottlenecked, and fix those to increase framerate.

I wasnt aware unity and its update loop was frame locked.

Lot of games make their update loop equal to or less than framerates precisely to avoid these headaches.

If you want to go a little fucky about your implementation, you could write a small executable to detect keyboard inputs and then pipe them over to unity, say through the network stack.

It's not like independent programs havent been used before to achieve something the existing tech doesnt have built in: nat punch-through for example.

My use case is music games, in which framerate-locked input detection may disadvantage players. osu! already solves that by multithreading the input detection, so I thought there ought to be a way to pull it off.

Plus, I'm using the new input system, which has a method to change the polling rate of the devices. So I thought I could just read the value from the API in a non-main thread because that poll rate modification API seemed to make input detection no longer framerate-locked somehow.

Well, it turned out I was dumb as f*<k not to research this through. The idea was not to read the value in the non-main thread; it's thread-unsafe and would inevitably crash the game. Instead, the right idea appears to be to create a buffer where the input system could queue the polled actions so that I could foreach on them in the main thread later. It seems each action comes with a timestamp, so that sounds like the way to go for me.

@clpsplug hows it going? Did you get it to work?

@Wisecrack Actually, yes! The buffer class 'InputActionTrace' seems to work without apparent framerate drop. In addition, all the input errors within the game often differ by just one millisecond, meaning it's not frame-locked anymore.

@clpsplug you may be able to accumulate and average out those errors btw.