> Argh... yes, I realize that the previous sentence was compressed a little too 
> much for comfort, but no, it's not line noise..
> 
> I'm going off the statement:
> 
> "... DTrace requires that each probe clause produce a fixed-length trace
> record. This means that the total number of bytes generated by all of
> the recording actions (trace, printf, etc.), for one clause, must be
> constant. Each clause can generate a different size record, but one
> clause must generate the same size record each time it is invoked. If
> the designers allowed flow control statements, the size of the trace
> record could vary, depending on whether the if condition was true."
> 
> 
> The way I parse this is that this limitation makes the following not work
> 
> if (cond) { printf("a"); } else { printf("aa"); }
> 
> because the first creates a trace 1 byte long, the second 2 bytes.

Well, this is a bad example, as these actually store the same amount
of data.  Regardless, quantity of data is actually the easier bit
of this problem; it is type of data that is more challenging.

That is:

  if (cond) { ustack(); } else { printf("Cond is false.\n"); printa(@); }

Is it possible to solve this?  Yes, of course -- it's just software after
all.  But does it make the system substantially more complicated for what
amounts to syntactic sugar?  Yes, again.  And by the way:  yes, you
can envision ways to tell lies to get this to work (e.g., by putting
each potential execution in its own clause with an appropriate
predicate), but again, it's complicated and (like many lies), the truth
will leak which will require patches of yet more lies.

We have what we have because it's simple in both model and implementation --
and there is (in my opinion) tremendous value in simplicity wherever it
can be reasonably had. 

        - Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Sun Microsystems Fishworks.       http://blogs.sun.com/bmc
_______________________________________________
dtrace-discuss mailing list
[email protected]

Reply via email to