絶望した！ポーリングでCPUを喰らい尽くすX Window Systemに絶望した！
参考リンク1と参考リンク2。
実際のところ、Gtk+ではビジーループを回しているのだろうか。我々はCO2の排出量削減のためにやけに暑いオフィスで仕事をさせられたりしているというのに、そんな富豪的な電力の使い方をしているのだろうか。本当であるとしたら、色々と考え直さねばならない事もあるだろう。そこで、実際にソースを読んで調べてみた。
Gtk+の場合、参考リンク2のコメントにあるConnectionNumberマクロを使ってfile descriptorを取得している。gdk/x11/gdkevents-x11.cの_gdk_events_initには以下のようなコードがある。
int connection_number = ConnectionNumber (display_x11->xdisplay); (中略) display_source->event_poll_fd.fd = connection_number; display_source->event_poll_fd.events = G_IO_IN; g_source_add_poll (source, &display_source->event_poll_fd);
g_source_add_pollはGtk+が利用しているglibのmain loopにevent sourceを追加するための関数である。glibのmain loopはやけに高機能でややこしいが、ソースを読んで見たところ、イベント待ちではpollが使える場合はpollを、そうでない場合にはselectを使っていると考えてよいようだ。つまり、Gtk+ではmain loopはちゃんとpollとかselectを使っているので、sleepして定期的にイベントの到着をチェックしたり、というようなことはしていないみたいだ。めでたしめでたし。我々も暑いオフィスで汗だくで仕事をしている甲斐があったというものです。
AIOに関してはそもそも使ったことがないのでよくわかってないんだけど、調べてみたところ、TheC10kProblemのページが見つかった。それによると、epol, aio, その他のイベントソースの統合に関する長い議論が 2002 年のハロウィンに起こったらしい。こんな長いスレッドを全部読んでられないので顛末とかはよくわからない。2006年にEvgeniy Polyakovがepollとaioを統合するためのパッチを送ったが、最終的には採用されなかったみたいだ。代わりに採用されたsignalfdに関するlwnでの解説。結論は
