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.
Thanks for advice about internal queue - this is how i managed to solve problem by now, but actually i was hopping there more elegant way to do it 2013/9/9 james <[email protected]> > On 09/09/2013 09:24, Артём Титов wrote: > >> Thanks for response! >> I know that, and I'm handling all messages inside "thread". It gets few >> messages, but when code exits callback method window stops to respond. >> > > So, what thread is it that handled the callback, and where is it > afterwards? Is it waiting on a win32 synchronisation primitive in WaitFor, > or is it actually processing Windows messages? > > It sounds to me like it is not idling in a Windows message processing loop. > > Personally, I would not recommend doing any windowing inside a network > event processor thread. Put data into an internal queue and post a message > to a window-handling thread when it goes to !empty. > > > -- Best regards, Artem Titov
