bug report/suggested temp. patch: handling bursts of sent keys

[Mark Lillibridge]

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/