Jon wrote: > Thanks for the patch. Have you actually tested that this resolves your > problem?
Yes. Of course, really, really large bursts will still fail, but they should be very rare. > I'll add some words about contributing patches to the CG guide > documentation, > thanks for pointing out this oversight. > > Perhaps that's the reason we hardly ever get any :-) You think? :-) > On 23/01/2010 22:02, Mark Lillibridge wrote: > > I am not a Windows programmer. Can someone tell me if it's okay for > > winWindowProc to block? In particular, could we make it block until the > > mieq queue is not full? > > I think blocking would just result in a deadlock, as the X server is only > single-threaded. The windows message pump is called when the server has no > other work to do. > > This should be documented in [1], although perhaps that is lacking in detail. > > I notice that winWakeHandler()/winBlockHandler() try to completely empty the > windows message queue, which leads to this problem as the server won't get a > chance to process anything (draining the mieq queue) until they return. > > It might be enough to resolve this problem to allow those functions to > complete after processing a limited number of events (chosen so as to not > overflow the mieq queue), or if they notice that the event queue has crossed > some high-water mark threshold. This is an interesting idea; I spent a while looking at WaitFor.c/WaitForSomething, but it's pretty opaque -- couldn't figure out when/under what conditions winWakeHandler is called by it. E.g., what's the actual priority between emptying the queue and processing window messages? - Mark -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/