Если и для обработчика хука и для нашего PostMessage будет использоваться одна и та же очередь сообщений, то может случиться так что сообщение для хук-обработчика будет поставлено в очередь во время обработки нашего PostMessage (поставленого в очередь во время предыдущего срабатывания хук-обработчика)и Windows просто не дождется когда же мы закончим этот PostMessage обрабатывать и изымем из очереди сообщение для хук-обработчика. Если же использовать разные потоки, то есть шанс что планировщик потоков прервет исполнение долгой операции и передаст управление потоку с хук-обработчиком до того как Windows решит прибить наш хук. Для повышения этого шанса можно еще и приоритет потока с обработчиком хука поднять до критического. Но все равно это не даст 100% гарантии что наш хук будет не тронут. Я дополнительно еще костыль лепил: в начале функции обработчика хука заводил таймер на 1.5 сек, а в конце его прибивал. Если таймер все же срабатывал, это значило что функция до конца не отработала и обработчик таймера переустанавливал хук. У меня стояла задача не просто мониторить события мыши/клавиатуры, но и блокировать их при необходимости. Поэтому функцию-обработчик хука и свой код по обработке я разнести по разным потокам не мог. Однако для хука я все-таки выделял собственный поток, т. к. программа делалась как плагин в виде dll для другой программы и хрен его знает что там в той программе на поток загрузивший мою dll было завязано