Browse thread
LablGTK app maxes out CPU
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2006-07-06 (23:50) |
From: | Matt Gushee <matt@g...> |
Subject: | Re: [Caml-list] LablGTK app maxes out CPU |
Jerome Vouillon wrote: > You should try to run your program with the strace program, which > traces system calls. This will tell you why your program runs > continuously rather than waiting for I/Os. Okay, I've done the strace. I found something that appears to be significant, but I don't really understand it. After the GUI is displayed, there are a number of GTK library calls, and then some searches for various resources--locale files, fonts, icons--and then this: poll([{fd=3, events=POLLIN}], 1, 0) = 0 write(3, "\1\30\r\0\3\0\340\0D\0\0\0\0\0\0\0\251\0\244\1\0\0\1\0"..., 2132) = 2132 ioctl(3, FIONREAD, [1184]) = 0 read(3, "\34\317N\0\3\0\340\0\31\1\0\0\376\331]E\0\330]Ex\202\37"..., 1184) = 1184 poll([{fd=3, events=POLLIN}], 1, 0) = 0 poll([{fd=3, events=POLLIN}], 1, 0) = 0 poll([{fd=3, events=POLLIN}], 1, 0) = 0 poll([{fd=3, events=POLLIN}], 1, 0) = 0 poll([{fd=3, events=POLLIN}], 1, 0) = 0 poll([{fd=3, events=POLLIN}], 1, 0) = 0 poll([{fd=3, events=POLLIN}], 1, 0) = 0 poll([{fd=3, events=POLLIN}], 1, 0) = 0 poll([{fd=3, events=POLLIN}], 1, 0) = 0 ioctl(3, FIONREAD, [0]) = 0 poll([{fd=3, events=POLLIN}], 1, 0) = 0 ioctl(3, FIONREAD, [0]) = 0 poll([{fd=3, events=POLLIN}], 1, 0) = 0 write(3, "5\30\4\0&\0\340\0\36\0\340\0\245\0\20\0\230\4\5\0\'\0\340"..., 13780) = 13780 ioctl(3, FIONREAD, [0]) = 0 poll([{fd=3, events=POLLIN}], 1, 0) = 0 ioctl(3, FIONREAD, [0]) = 0 poll([{fd=3, events=POLLIN}, {fd=7, events=POLLIN, revents=POLLHUP}], 2, -1) = 1 The last two lines are then repeated around 18000 times (identically each time, as far as I can see), until the 'quit' command is received. This takes place over a span of perhaps 30 seconds of real time. So pretty clearly this is the CPU-eating behavior, but I still can't see what is triggering it. By the way, FD #7 is my FIFO. Well, based on the above, I tried adding a second watch function: let hup_watcher _ = Util.sleep 0.25; true in (* ... unrelated code omitted ... *) ignore (GMain.Io.add_watch ~cond:[`HUP] ~callback:hup_watcher chan) Finally, this produces a change in behavior--but not quite what I need. CPU usage is under control, but now the GUI fails to display completely: the main window appears, with the outine of the TreeView widget it is supposed to have, but the contents are never displayed. -- Matt Gushee : Bantam - lightweight file manager : matt.gushee.net/software/bantam/ : : RASCL's A Simple Configuration Language : matt.gushee.net/rascl/ :