Events and event handling under the hood

Question

I\'ve just been working through some simple programs using SDL and it made me think back to some Java GUIs I\'ve written.

In the simple SDL programs, I have a loop that

Answer 1

As said by answerers before, it is system specific, and could be implemented either way.

If I remember the Windows API right (long years ago), there was a "Window function" which got called for every event, and I made a big switch to choose the right action depending on event type.

I think most toolkits abstract this away, like the Java AWT with its event dispatch queue.

For the X protocol, the input events (as well as "your window needs to be painted") come as event messages over the wire, and it is up to the toolkit library to convert this either in a application function call or add them to a queue to be queried later.

The X protocol in fact works (basically) with two byte-streams: one from application ("client") to system ("server"), one in the other direction. The client sends request packages, the server sends back results (for some types of requests), errors (if some request could not be fulfilled for some reason), and events (when something happens on the display, like a mouse move, key press, window resize, ...).

For local displays on modern systems this is usually implemented by some shared memory mechanism, but in principle this can go over TCP (or today mostly over SSH) for remote connections (thus "over the wire").

I once started to create a pure Java X client implementation (didn't complete, as I found other more interesting things to do), and there I simply used a Socket with its InputStream and OutputStream to connect to the server. Thus, in principle I used the blocking native read() function of the Socket-InputStream to wait for events (and results and errors). I could have used a java.nio.SocketChannel in nonblocking mode, too, and then basically I would had a polling loop (doing other things between, of course). (Or I could use a selector, waiting until new readable data is there - thus blocking, too.)

I have no idea what mechanism the AWT-for-X implementation used by the Linux and Solaris implementations of Java are using - I suppose they are based on some native toolkit, which in turn is based on the X client library (for C) "Xlib", but I don't know whether there is polling, blocking wait or being called by someone in the base.