I've done a bit more investigating. It appears that winWindowProc can block at the cost of preventing processing of any Windows messages until it returns. Does anyone know how fast the mieq queue drains? If this isn't very fast, then having winWindowProc block waiting for the mieq queue is probably a bad idea.
There are a number of comments in mieq.c that may shed light on why the queue is statically allocated: mieq.c:76: EventRec events[QUEUE_SIZE]; /* static allocation for signals */ mieq.c:138: /* * Must be reentrant with ProcessInputEvents. Assumption: mieqEnqueue * will never be interrupted. If this is called from both signal * handlers and regular code, make sure the signal is suspended when * called from regular code. */ void mieqEnqueue(DeviceIntPtr pDev, InternalEvent *e) Does anyone understand this? Does this bar dynamically allocating the queue? The queue does not appear to use locking unless XQUARTZ is defined. Does anyone know what conditions that is defined under? I'm beginning to think that simply patching the queue to be very large is the best solution. - 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/