Hi people! I'm making my small game engine and my game loop consist of 3 classic steps:

1. Handle all user input (so handle all windows messages).
2. Update internal stuff.
3. Draw a frame.

And so I thought about latency. While we are on steps 2 and 3 we don't handle user input and so it's being delayed. It's not a problem because once we submit a frame we handle all input again and so we draw the next frame with the almost latest input data. My question is about networking. If for example, we have an onMousePress() function and sendMousePressEventToServer() function inside of it this 3-step pipeline basically adds additional delay to the ping which depends on the FPS and that's not good.

On the other hand, if we had a separate thread only for the user input that is constantly running and handling user input we could solve this issue. Of course, this would require some synchronization but only for some functions not all of them.

Are there any pitfalls in the separate thread approach?

First thing that comes to mind is to avoid busy-waiting. You would need a way to control the input frame-rate so you choose the amount of lag you have for input (ie. target 240fps of input checks). Instant reaction to input I think it's impossible unless you have input coming from the operating system on a different thread on some callback you register.

Flone said:
Handle all user input (so handle all windows messages).

You don't want to do that! Windows messages are messed up with a lot of stuff that you don't need and so you should never (even if most tutorials do so) do the entire game and message handling in the main thread! The message loop was meant to be used by user programs so an editor or some word processing software, which isn't meant to run “realtime”. A game is much different and Microsoft early added their Direct Input system to compensate that for games.

In order to give your player good reaction times, it is necessary to get input as fast as possible but it doesn't mean that you are supposed to handle that input on the same thread. A usual way to solve this is adding an Input Manager/Input Event System that will be feeded with the input and flushed once in a while when the gameloop is ready to handle it. Input is also usually seeded with a timestamp or delta which is the time when the input arrived vs the time when the frame started.

A network environment is even different. If the network programmer made it's job well, everything that comes from a server is in it's own thread by default, to not stall the entire game for waiting for server messages to arrive. So you perform the message loop in your main thread, grabbing everything input related and send that to the server immediately (it depends on the architecture of your game in the final case) and feed incoming messages into the Input Manager/Input Event System as well.

Flone said:
On the other hand, if we had a separate thread only for the user input that is constantly running and handling user input we could solve this issue.

You won't even do that! What you can do is to implement some kind of work scheduling which will execute different tasks your game might have and also adds the Input Manager/Input Event System dispatching as a task. This way you still may have some minor input lags but don't waste an entire thread to input processing