> By thread i meant context in which callback was called, actually there is no threading that done by me - only libevents callbacks. So there only issue is window that was created by win api inside callback function stop responding (and getting signals) when step out from callback function.Well, the thread that is running the callbacks came from somewhere, and when it is not in the callback it is doing something - probably blocked on an event.
Look here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms687069(v=vs.85).aspx <http://msdn.microsoft.com/en-us/library/windows/desktop/ms687069%28v=vs.85%29.aspx>
If the thread is waiting using WaitFor... then it will have no chance of handling window messages. If it is in MsgWaitFor... then it has some chance, providing it is receiving and dispatching window messages. And while old fogeys like me used to write dispatch loops, they are often hidden inside GUI libraries which might need to perform unusual processing.
Now I don't actually have a current source for libevent and haven't looked in one for a while, but I would be quite surprised if it waited in a way that dispatched window messages.
You are much better off running your UI in a dedicated thread (which may be the main thread) where whatever UI library you have can run the event loop as it sees fit and running something like libevent (or other similar things) in threads created for that purpose - and not doing any interaction with Windowing from those threads beyond notifying them with PostMessage or PostThreadMessage.
Note that a single threaded COM apartment is also expecting to run in a thread that processes window messages.