The preferred way is as suggested by ApochPiQ. You must, and I repeat absolutely must use events to handle input. Have you ever played a game that forgot to fire even though you clearly hit the fire button? Only via polling can this happen. And it is extremely irritating to any human when it happens.
Listening to events is the only way to ensure this never happens.
And only by listening to events on a second thread is this guaranteed to work as promised. Smooth mouse movements require this, and there is some work involved in making it happen correctly, but your players will appreciate it.
This is interesting. Thus far I've always let the input reading(via polling or events) be done in the same thread as the game loop. But I see the issues with this and have encountered many of them in the past, though I've never considered multithreading the input as an option.
Now, if we disregard polling, should it be done by running your message loop in a separate thread or the way DirectInput does it, with a hidden window that only handles input messages? My guess is the first option, but I may have overlooked something, like a third option, hence the question.