dtrace discuss - Apr 2009 - Proposed addition to Scripting chapter

Here''s a stab at including something on flow control in the wiki. I
feel like it needs a killer example. Something less contrived than the profile
loop and less complicated than what''s in speculative tracing. Any
ideas?

Suggestions, improvements?

***
Flow Control in D Programs

The dtrace provider maintains three probes -- BEGIN, END, and ERROR -- that
allow a D program to perform initialization, summation and/or resource cleanup
as desired.

When a probe fires, its actions execute in program order. If the same probe is
used in multiple clauses, the actions will execute in program order for each
clause with no predicate or a predicate that evaluates to true. A D program can
therefore implement flow control in one of two ways: by using a thread-local
variable as a predicate test in any subsequent probe firing, or by any predicate
test in a subsequent clause that declares the same probe.

With the profile provider, for example, you can use a measure of time as an
iteration. The following script will report the time every minute for ten
minutes, then terminate:

int n = 0;

profile:::tick-1sec {   n++; }

profile:::tick1-sec
/ n % 60 == 0 /
{   printf("%Y\n", walltimestamp); }

profile:::tick1-sec
/ n == 300 /
{ exit(0); }

dtrace:::END
{   printf("Five minutes are up.\n"); }

Note the END probe fires after the exit() action executes.

The /usr/demo/dtrace directory contains several examples of thread-local
variables used branch conditions in predicates. For a complex example of flow
control, review the chapter on Speculative Tracing.

Prefer predicates that use thread-local or immutable values. For more
information, refer to the section "Use Cacheable Predicates" in the
Performance Considerations chapter.
-- 
This message posted from opensolaris.org

Hey Michael,

Where is this intended to go in the documentation? Further, this
doesn''t
really sound like flow control, more like the lifecycle of a D program.

What resource cleanup do you think could be performed in the BEGIN, END or
ERROR probes?

Adam

On Tue, Apr 21, 2009 at 10:57:12AM -0700, Michael Ernest
wrote:
> Here''s a stab at including something on flow control in the wiki.
I feel like it needs a killer example. Something less contrived than the profile
loop and less complicated than what''s in speculative tracing. Any
ideas?
> 
> Suggestions, improvements?
> 
> ***
> Flow Control in D Programs
> 
> The dtrace provider maintains three probes -- BEGIN, END, and ERROR -- that
allow a D program to perform initialization, summation and/or resource cleanup
as desired.
> 
> When a probe fires, its actions execute in program order. If the same probe
is used in multiple clauses, the actions will execute in program order for each
clause with no predicate or a predicate that evaluates to true. A D program can
therefore implement flow control in one of two ways: by using a thread-local
variable as a predicate test in any subsequent probe firing, or by any predicate
test in a subsequent clause that declares the same probe.
> 
> With the profile provider, for example, you can use a measure of time as an
iteration. The following script will report the time every minute for ten
minutes, then terminate:
> 
> int n = 0;
> 
> profile:::tick-1sec {   n++; }
> 
> profile:::tick1-sec
> / n % 60 == 0 /
> {   printf("%Y\n", walltimestamp); }
> 
> profile:::tick1-sec
> / n == 300 /
> { exit(0); }
> 
> dtrace:::END
> {   printf("Five minutes are up.\n"); }
> 
> Note the END probe fires after the exit() action executes.
> 
> The /usr/demo/dtrace directory contains several examples of thread-local
variables used branch conditions in predicates. For a complex example of flow
control, review the chapter on Speculative Tracing.
> 
> Prefer predicates that use thread-local or immutable values. For more
information, refer to the section "Use Cacheable Predicates" in the
Performance Considerations chapter.
> -- 
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
-- 
Adam Leventhal, Fishworks                     http://blogs.sun.com/ahl

Thanks Adam.

I thought there was a common theme that naturally brought the
"lifecycle" probes and the flow control discussion together.
Doesn''t really work. I think some comment on program lifecycle in the
scripting chapter is appropriate, but I don''t know if it add much to
what''s already in the dtrace provider chapter.

I wrote in the idea of resource cleanup while thinking (vaguely) of aggregation
and speculative buffer cleanup in ERROR. I didn''t have a case in mind,
so I''ll give that more thought. I''d like to include some
examples for BEGIN/END/ERROR that get away from the awk-ish business of column
headers and totals footers and bombing out with an arguably helpful message.

Here''s another swipe:

***
D Program Flow Control

The most common approach to flow control in a D program sets a thread-local
variable in one clause, then tests for its existence (or value) in a subsequent
clause. Using this approach, a D program can ensure it only processes actions
upon the return of a probed function if it observed the entry to that function.

A probe declared in multiple clauses will process its actions in program order,
except for any clauses whose predicates evaluate to false. By using probes in
multiple clauses and predicates that create branching conditions, a program can
effect a form of flow control. Since clause-local variables have probe-level
scope, all clauses common to one probe will share any clause-local values.

The D language does not support looping, but a D program can fashion one from a
repeating event such as a time interval. The following program uses one probe to
count seconds, report each minute completed, and terminate after five minutes:

profile:::tick-1sec
{   this->n++; }

profile:::tick1-sec
/ this->n % 60 == 0 /
{   printf("%Y\n", walltimestamp); }

profile:::tick1-sec
/ this->n == 300 /
{ 
   printf("%d seconds are up.\n", this->n);
   exit(0); 
}

For an example of multiple clauses and predicate conditions used to manage flow
control, see the "Speculation Example" section in the Speculative
Tracing chapter.
-- 
This message posted from opensolaris.org