Advertisement

knowing when an XEvent is available

Started by April 28, 2009 04:14 PM
3 comments, last by bradbobak 15 years, 6 months ago
My current XLib interface is using a single thread to call all XLib functions. I basically wrap the xlib call data from another thread, add it to a queue and have the main thread perform the call. This is working fine, but my problem lies in knowing when XNextEvent will return an event from outside the calling thread. Currently, my event loop processes all available events, then it sleeps for 20ms, if no events, 40ms, 60ms, all the way up to 200ms. I realize that this is sub-optimal and I am hoping to find a way to determine if an event is available (or possibly available) from another thread. I am thinking of blocking on the Display socket until something to read is available, but I'm not sure that this will work. So I am asking in hopes someone has an alternative to my 'busy wait' solution. Thanks, Brad.
Would XPending be what you're looking for?
Advertisement
No. Basically what I am doing is running one thread which communicates with X. Any thread can tell this thread to call a Xlib function and return the result.
My event loop (its own thread) calls the above thread to do a XPeekEvent() to see if there are any events. If there is none, it sleeps for a small amount of time and asks for another XPeekEvent() response. Effectively, this is a busy-wait kind of thing. Rather than sleeping, I would like it to block until another event is available.
Because I read threading in Xlib is not so good, this is why I have only one thread dealing with the XLib and the other threads making requests through the XLib thread. Effectively, I cannot have the XLib thread blocking on an XNextEvent() because other threads may request some XLib action.
So, I need to know when a new event comes in from the X-server in the event loop thread so it doesn't have to sleep / poll / sleep / poll..

I have no idea how thread-safe XNextEvent() is. If I could have a thread blocking on XNextEvent() while another is sending other requests to XLib this would be optimal. Otherwise, I need some sort of mechanism where I can tell a new event has arrived from the X-server (I was thinking of selecting on the X connection socket).

just to illustrate, this is how things work:

  thread xinterface  {    process_xlib_request_and_return_result;  }  thread event_loop  {    call xinterface [XPeekEvent]    if (no event) sleep_a_bit, start again <-- here I need to avoid the sleep somehow    else process event, start again  }  thread some_other_thread  {    call xinterface [XCreateWindow]    call xinterface [...]  }
Firstly why all the threads?

Quote:
Rather than sleeping, I would like it to block until another event is available.

You could check the count of a semaphore or wait a condition variable in the event thread.
I don't know, I was thread happy.

I suppose the event loop can run in the main thread.

main thread:
open_window
run_event_loop

timer thread (or networking notify thread, etc)
how can I send a message to the main thread. Is XPostMessage(...) thread safe? If so, then
I could send a client message to the window and have it poll the timer / network stack.

So I guess my big question is, can I use XPostMessage(...) from a separate thread and not have it interfere with the main thread be it in the middle of copying a pixmap, or just waiting for XNextEvent. And is this optimal? If my timer ticks very frequently, will the XPostMessage() / XNextEvent(client message) be negligable?


This topic is closed to new replies.

Advertisement