Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!well!bschoen From: bschoen@well.sf.ca.us (Brook Schoenfield) Newsgroups: comp.windows.x Subject: Re: Event Loops Message-ID: <24338@well.sf.ca.us> Date: 21 Apr 91 04:47:43 GMT References: <24267@well.sf.ca.us> <1991Apr18.000420.7600@mprgate.mpr.ca> Distribution: na Lines: 49 janzen@mprgate.mpr.ca (Martin Janzen) writes: >> for (;;) { >> if (XtAppPending(WindowOne)) >> XtDispatch(); > >> if (XtAppPending(WindowTwo)) >> XtDispatch(); >> } >> >>This method works fine. The only problem I have is that >>I have to poll for events; this means I am never really >>waiting (blocking) and I am burning a lot of CPU. > >>XtAppPending() returns whether or not an event is avaliable: >>why not use XtAppNextEvent(), which blocks until an event is >>available? >Be careful with this. If your application contexts (call them app1 and app2) >are connected to different displays, and you call XtAppNextEvent(app1, &event) >when no events are pending on the display connection for app1, then your >process will block until the next event is received on *that* connection. >No events in app2 will be processed until an event occurs on the display >connection for app1. Thanks much for the correcttion on the multiple display problem: I forgot about blocking the second display. >You didn't mention this in the original message, but anyone who needs to do >background processing should check out XtAddWorkProc/XtRemoveWorkProc... As long as you don't expect these calls to to take care of timeing: this is exactly what I refered to in my first posting: these will be sent out as fast and as furiously as possible. If all you do is get one of these, do your work and then set up the next one you will be in the same position as your first problem. You will tie the machine up completely. Good Luck -- Brook Schoenfield bschoen@well.sf.ca.us "How can our technology be used to create a peaceful, well fed world?" - burning question