Chris Andrews
2008-Nov-24 16:33 UTC
[dtrace-discuss] DTrace helper interface''s deprecated ioctls
Hi, Is there a specific reason the DTRACEHIOC_REMOVE ioctl is deprecated? I found I needed to use it in my Perl USDT provider code[*], which creates providers dynamically at runtime. I wonder if I''m missing a better way of doing the same thing. The situation I''m handling with the remove operation is killing and recreating a perl interpreter in the same process, which Apache/mod_perl does on startup. Without the remove call, the probes created by the first interpreter are still around, but are unknown to the second interpreter - a subsequent ADDDOF for the same provider doesn''t appear to update existing probes. Thanks, Chris. * - http://search.cpan.org/~chrisa/Devel-DTrace-Provider-0.02/lib/Devel/DTrace/Provider.pm
Adam Leventhal
2008-Nov-27 00:32 UTC
[dtrace-discuss] DTrace helper interface''s deprecated ioctls
Hi Chris, It appears that the comment in dtrace.h regarding DTRACEHIOC_REMOVE is just wrong. If I remember correctly, when I added DTRACEHIOC_ADDDOF I had considered adding a new remove version as well, but didn''t end up needing it. I believe that that was the source of the comment. That perl module is very very cool; nice work! It''s a bit like the JUSDT stuff that the Java folks have been working on. Should we call it PSDT? The support for removing providers is a bit spotty so you many encounter some problems. Please let me/us know if/when you do. Adam On Nov 24, 2008, at 8:33 AM, Chris Andrews wrote:> Hi, > > Is there a specific reason the DTRACEHIOC_REMOVE ioctl is deprecated? > I found I needed to use it in my Perl USDT provider code[*], which > creates providers dynamically at runtime. I wonder if I''m missing a > better way of doing the same thing. > > The situation I''m handling with the remove operation is killing and > recreating a perl interpreter in the same process, which > Apache/mod_perl does on startup. Without the remove call, the probes > created by the first interpreter are still around, but are unknown to > the second interpreter - a subsequent ADDDOF for the same provider > doesn''t appear to update existing probes. > > > Thanks, > Chris. > > * - http://search.cpan.org/~chrisa/Devel-DTrace-Provider-0.02/lib/Devel/DTrace/Provider.pm > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Adam Leventhal, Fishworks http://blogs.sun.com/ahl
Possibly Parallel Threads
- autoconf test for building dtrace USDT probes?
- ricoh ap204/3800c
- 6370454 dtrace should support USDT probes in static functions
- Hekp dtrace -l is bleeding Unstable implementation details all over my USDT probe namespace :(
- Question about -xlaxyload option to dtrace -G