Wednesday, 13 July 2011

dtrace gripe

I really dislike some aspects of dtrace. Its a great tool,
but the "lets pretend we are C" when it isnt is a nuisance.
Macro languages should be designed to be expressive, but
dtraces' D language is annoying.

Firstly, the lack of if-then-else is a problem. It leads to
convoluted use of ?: (which cannot handle multiple statements).
I really dont understand why if-then-else isnt there. It doesnt
harm the "Thou shalt not have loops" which can lock up a kernel.

Whats annoying is that the C programming language, and D, copying it,
does it to an extent that is .. well, annoying !

Consider this: I want a probe which can exit after 5s of execution
time. Heres the naive implementation:

t = timestamp;
tick-1ms {
timestamp - t > 5*1000*1000*1000 ? exit(0) : 1;

This isnt possible, because exit(0) is a void function.

t = timestamp;
tick-1ms {
timestamp - t > 5*1000*1000*1000 ? (int) exit(0) : 1;

But, oh-no! You cannot cast a "void" to an "int". In C, I can understand
that (almost) but it leads to painful workarounds. In D, there is even
less reason: if a (void) could be cast to "(int) 0", then the above
would work. Its still ugly, but functional.

The actual solution is:

t = timestamp;
tick-1ms / timestamp - t > 5*1000*1000*1000 / {

Which is fine - although I havent determined if the predicate is
worse or more expensive than the actual code. What is annoying is that
the predicate is a "different part of the language". What if I wanted
to do this:

tick-1ms {
if (var > somevalue) { printf("hello"); exit(0);}
if (var > someOthervalue) {printf("world"); }

This can be translated into predicate format, but this can involve
ugliness in performing the transformation, especially if the do-stuff
lines of code are complex in themselves.

Its time to start addressing these deficiencies in Dtrace (at the risk
of being non-standard extensions to the true code).

Post created by CRiSP v10.0.12a-b6033

1 comment:

  1. There's a good reason for this. Each ECB needs to have a fixed size data payload. If you want to if (foo) trace(1); else trace("one"); that wouldn't be the case. That said it also would have been possible to relegate that sort of nuance to the level of an implementation detail rather than a front-and-center language attribute.