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

[Bengt-Arne Fjellner]

On 2010-02-01 12:33 AM, Mark Lillibridge wrote:
> 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
>
>
>    
Well XQuartz is what the server is called on Mac OS X

--
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/