#5991: regression: huge number of wakeups in xmonad
--------------------------------------+-------------------------------------
Reporter: dmwit | Owner:
Type: bug | Status: new
Priority: high | Milestone: 7.4.2
Component: Runtime System | Version: 7.4.2
Resolution: | Keywords:
Os: Linux | Architecture: x86_64 (amd64)
Failure: Runtime performance bug | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: | Related:
--------------------------------------+-------------------------------------
Changes (by def):
* cc: dennis@… (added)
Comment:
This problem also occurs with a stock xmonad config. I tracked it down
even further and have a minimal example now:
{{{
import Graphics.X11.Xlib
main = do
dpy <- openDisplay ""
allocaXEvent $ \xevent ->
nextEvent dpy xevent
}}}
100 wakeups per second using GHC 7.4.2. The same program in C does not
have this problem (compile with gcc -lX11 -o min-x11 min-x11.c):
{{{
#include <X11/Xlib.h>
int main(int argc, char **argv) {
Display* dpy = XOpenDisplay(NULL);
XEvent xevent;
XNextEvent(dpy, &xevent);
}
}}}
The problem is related to blocking in a foreign call (in this case waiting
on the socket /tmp/.X11-unix/X0). When the nextEvent' from
[http://www.haskell.org/haskellwiki/X_window_programming_in_Haskell] is
used instead of nextEvent the problem disappears. It waits using Haskell's
threadWaitRead instead of doing it inside the foreign call.
I have also found another instance of this problem when using GTK (it's
also /tmp/.X11-unix/X0):
{{{
import Graphics.UI.Gtk
main = do
initGUI
mainGUI
}}}
Again no problems with the C version (compile with gcc $(pkg-config
--cflags --libs gtk+-2.0) -o min-gtk min-gtk.c):
{{{
#include <gtk/gtk.h>
int main(int argc, char **argv) {
gtk_init(&argc, &argv);
gtk_main();
}
}}}
I could upload the strace outputs of the C and Haskell versions which show
what they do differently. Tell me if there's anything I can do.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5991#comment:14>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
