dtrace discuss - Apr 2006 - how to define a parametric profile:::tick-Nsec

I''d like to define a parametric profile:::tick-Nsec probe like the
following:

profile:::tick-$1sec { exit(0); }

where $1 is a command line parameter given by the user to the D script which
specifies after how many seconds the script should exit(0). Is this possible?
 
 
This message posted from opensolaris.org

alessioc''s email at 4/27/2006 8:35 AM, said:
> I''d like to define a parametric profile:::tick-Nsec probe like the
following:
> 
> profile:::tick-$1sec { exit(0); }
> 
> where $1 is a command line parameter given by the user to the D script
which specifies after how many seconds the script should exit(0). Is this
possible?
>  
>  
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
> 
> 
profile:::tick-1sec
/ ++x >= $1 /
{
	exit(0);
}



Thanks,

Jarod

> profile:::tick-1sec
> / ++x >= $1 /
> {
> 	exit(0);
> }
OK, is there a "better" solution to do that? :)
I mean, having something like profile:::tick-$1sec, where $1 is being replaced
at pre-processing time, would lead to an O(1) function to handle timed exit.
The above solution is O(2n).
Having big n (eg. 3600=1 hour), the difference between O(1) and O(2n) is quite
relevant... and even if D is lightweight and the performance difference would be
just a few picoseconds, it''s just "unelegant" to call 3600
times the tick function without a real needing, isn''t it?

On Thu, Apr 27, 2006 at 04:22:30PM +0200, Alessio Cervellin
wrote:
> > profile:::tick-1sec
> > / ++x >= $1 /
> > {
> > 	exit(0);
> > }
> 
> OK, is there a "better" solution to do that? :)
> I mean, having something like profile:::tick-$1sec, where $1 is being
> replaced at pre-processing time, would lead to an O(1) function to
> handle timed exit.
> The above solution is O(2n).
> Having big n (eg. 3600=1 hour), the difference between O(1) and O(2n)
> is quite relevant... and even if D is lightweight and the performance
> difference would be just a few picoseconds, it''s just
"unelegant" to
> call 3600 times the tick function without a real needing, isn''t
it?
While it might seem like there should be a better solution, what Jarod
suggested is actually better than what you''re suggesting. A tick-10s
probe,
for example, is guaranteed to fire once every 10 seconds, and while it may
first fire 10 seconds after BEGIN fires, it''s just as likely that it
fires
1ms after BEGIN. In other words, your program will run anywhere from 0 to
10 seconds. With Jarod''s solution, it will run from 9-10 seconds. In
general
you should pick the necessary resolution and do something like this:

BEGIN
{
	start = timestamp;
}

tick-<resolution>
/start + <delta> <= timestamp/
{
	exit(0);
}

Adam

-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl