1 Feb 2010 04:50
Re: bug report/suggested temp. patch: handling bursts of sent keys
Bengt-Arne Fjellner <Bengt-Arne.Fjellner <at> ltu.se>
2010-02-01 03:50:42 GMT
2010-02-01 03:50:42 GMT
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?(Continue reading)
I've finally got around to updating the Cygwin/X User Guide [2] to take note
of this fact
[1]
RSS Feed