   Keyboard/mouse Input use thread or child window?
  Ok, I've posted a similar post before, but this time is a bit different.  Alright, I'm coding under MS VC++ 6.0 .Anyway, If your boss says that you have to use multi-thread to capture keyboard and mouse input as background thread.  What are you going to do?  Right now, I can think of 2 different ways of doing that.First way, create user level thread and do some synchronization.  By doing this way, everytime there is a job for I/O thread, we have to use "EntryCritialSection" or so to let the I/O thread process the input first, and then the main thread has to wait until the I/O thread exit the critial section before it can move on the next I/O message.  Although, it can take any other messages while the I/O thread is running.  But there is nothing much different than single thread, isn't it?In addition to the first solution, if there are more than 1 background thread that share the same message queue, the main thread has to wait until everyone of them finish its job everytime before moving on -- which is just like single thread in the worse case.Second way, but I'm not sure if is possible.  Create a kernel space thread, which is (to me) actually create a child window has it's own message queue.  The messages come from the OS and the main thread (main window).  However, I've never tried this before and not sure how to start with.If the second solution is possible, I don't need to worry about synchronization on the user space since the OS already takes care of that. But that, probably, it might reduce the performance - I'm not sure.Any PRO and CON would be helpful. Thank you very much.   
  Defining user interface threads depends a lot on what exactly your program is doing, and how the existing threads are set up. Is there a main window in the program? Several small windows? Does the program do many "quick" tasks or one primary task that is highly resource-intensive? Why is your boss telling you to use multithreading in the first place? (i.e. are you doing this to use the multithreading buzzword in your marketings docs, or is there a good reason?)   ;  That is actually a game, something like RPG, racing, 1st personal shooting. But we are trying to develop an engine that use mulit-thread, including using input thread.   ;  It sounds to me (and please feel free to correct me if this is a misconception) that you're using threading because it's a cool buzzword, not because you've designed a system where it is actually needed.If you have multiple threads, blocking them all for your input thread to run totally defeats the point. In any case, in a game scenario, odds are you'll spend more time locating and fixing (or hacking around) synchronization problems than will ever be worth it. In fact, it's likely that the overall performance will be worse in most cases if you're not extremely careful with your threading and synchronization.If you still absolutely need to have a separate input thread, here's what I would personally do: - Split off a thread for input. For things like ::GetAsyncKeyState(), DirectInput, etc. there is no need for a Windows message pump. You can implement a working input system with just Win32 API calls without needing a window. In the worst case, where you are using Windows messages for input, your thread will have to create and manage the main rendering window. In this case, it is likely that threading is the wrong way to build your engine. - Have the input thread convert the raw user input data into commands for the rest of the engine using the Command design pattern. Each time the input thread runs, queue up these commands. Then lock on a command queue that is shared in your entire engine (using a mutex is the easiest way to do this locking). Add the commands into the shared queue, then unlock.You will have to plan things extremely carefully, because your input thread will run at a different pace than the rest of the engine. This means it is possible for things to get out of sync and introduce very nasty bugs and glitches if you aren't careful from the beginning.   ;  why not just use direct input in buffered mode and let the os/drivers manage?   ;  Thanks for the responds. First of all, about Direct Input, I personally never touch it.  Of course I can learn, but stand on C/C++ would be the most time saving to me.I think maybe I can take a look at the "GetAsyncKeyState()" function to see how it works.  I guess this would be probably a good way to start with.Yeah, user input is sorta the main source that drives the game to run.  And really, it's might not be that helpful using a thread for just the I/O.Thanks   