Archive for December, 2005


Wednesday, December 14th, 2005

DTrace looks nice, but it is not as-if the means to do what it does
haven’t been along for a long time.

My humble contribution: strace-account.
To use…

strace -o ~/ttt top
# q when you get tired
strace-account ~/ttt | less

from which we learn:

Cumulative Syscall Times.

Syscall  Count  Time(s)
select       8    19.42
read      3939     0.06
open      3165     0.04
close     3172     0.03
alarm     2142     0.02
stat      1565     0.02
fcntl     1523     0.01
(other)    336     0.01

Repetitive File Name Usage.

This is a list of files that are accessed, one way or another, at least
twice.  Note, that current directory is not being tracked.

Count  Filename                   
   14  /var/run/utmp
    8  /proc
    8  /proc/1
    8  /proc/1/stat
    8  /proc/1/statm
    2  /proc/meminfo
    2  /proc/stat
    2  /usr/share/terminfo/x/xterm

Small-Chunk File Input/Output.

This is a list of files that are accessed in small chunks.  "Badness" is a
heuristic measure of this.  The list is truncated at badness 2.00.  A file
can appear more than once if it is opened more than once.

Badness  Bytes  I/Os  File                       
  12.75  38784   102  /var/run/utmp
  12.75  38784   102  /var/run/utmp
  12.75  38784   102  /var/run/utmp
  12.75  38784   102  /var/run/utmp
  12.75  38784   102  /var/run/utmp
  12.75  38784   102  /var/run/utmp
  12.75  38784   102  /var/run/utmp
   2.67   2122     8  /usr/share/terminfo/x/xterm
   2.26  40878    23  (stdout)

My interpretation of this version of top’s output is that it is
opening way too many files way too many times. why is it also
calling stat(2), alarm(2), and fcntl(2) so often? [So it can connect
to /var/run/nscd/socket in non-blocking mode over and over again, if
you must know.] It also likes to read utmp many, many times in little

(strace-account is a bit of a hack. An strace with an output format
more suited for machine reading would be nice. It might even have
appeared since whenever I wrote strace-account.)

ABI/API Stability

Wednesday, December 14th, 2005

Both GTK+ and Gnome promise ABI and API stability.

But what does that mean?

To me it means that updating API/ABI stable libraries should not
break existing applications. This should not keep one from fixing
bugs — if you depend on those you get what you deserve — but
existing, well-defined, well-documented interfaces ought to continue working as previous.

The recent updating-glib-breaks-pango issue could, with a little good will, be considered a case of a
bug in old pango that now have triggered.

But what about the new updating-gtk+-breaks-stuff issue? Evidently soneone though it would be nice to change the basic ways reference counts are handled for GTK+ objects. That causes leaks, and leaks for widgets can mean they stay visible when they should not have been, i.e., applications are now broken. This is not right!

There is some talk about fixing the GTK_OBJECT_SET_FLAGS macro (and presumably the GTK_OBJECT_FLOATING macro) to plaster over the issue and regain some amount of API compatibility. The ABIs would remain incompatible,
so someone updating their libraries would still see their
applications break and come to me.

What can I as an application programmer do about this?

  • Demand that the GTK+ changes be rolled back. That would be the right
    thing to do and is a very reasonable demand. They could go back in for GTK+ 3.
  • Throw in some “incompatible with GTK+ 2.9 and later” dependency
    and get it deployed. Awful, right? Deployment is a multi-year
  • Rush in some devious works-both-places code and get that
    deployed. Marginally less awful, but still suffers from the deployment delay.

Incidentally, it is not at all clear what tangible benefit there
is to the changed reference count scheme. I am all ears.