Date: Tue, 13 Jan 2004 13:53:48 +0000 From: jonathan.foster@philips.com Subject: Re: [nanogui] nano-x and multi-thread Hi, > when using multi-thread method, GrGetNextEvent() would be affected? > It seems that the speed getting next event from events' queue become slow. > I am not sure about it. > Could you give me some advice on it? Are you trying to have one thread that does GrGetNextEvent() while another draws graphics? That won't work. If you enable THREADSAFE, your graphics calls should block until GrGetNextEvent() returns. If you disable THREADSAFE (or are using an old version of Microwindows that doesn't have that option), the code will be incredibly racy and probably not work at all. The best you can do is to GrPrepareSelect(), perform the select() yourself (with a timeout), then do GrCheckEvent() to get the event if available. Do not use GrServiceSelect() as that is racy and may block. Do not do GrGetNextEvent() since there may not be an event available (you'll also get woken up if you do a call that returns a value - e.g. creating a GC). This is still racy, but the race condition will be rare and can be worked around by having a suitable timeout on the select() (e.g. 100-250ms). The race condition is: Event thread: GrPrepareSelect() start Event thread: GrPrepareSelect() done Server: Sends event Graphics thread: GrNewGC() start Server: Sends new GC ID Graphics thread: Reads event and queues it locally Graphics thread: Reads GC ID Graphics thread: GrNewGC() done Event thread: select() start Since no data is available on the socket, select() will block. However, you want it to return immediately because there is an event on the queue. I have some ideas about how we might solve this race, but I haven't had chance to implement them - hence the kludge of having a timeout on select(). Kind regards, Jon Foster -- --------------------------------------------------------------------- To unsubscribe, e-mail: nanogui-unsubscribe@linuxhacker.org For additional commands, e-mail: nanogui-help@linuxhacker.org