I just noticed that if you put a commit in a clause after other actions, you get: commit( ) may not follow data-recording action(s) But if you read this and then move the commit to earlier in the clause, you get: data-recording actions may not follow commit( ) So, two comments: 1. This is a case where a more general error message would probably have been more helpful than the more specific ones. 2. Why can''t they be combined? If the data recording actions are not after a speculate, I don''t even see how they are related. I could see if the commit went off into some other part of the dtrace code and the rest of the actions were not executed that having the commit be first would be a problem, but then a commit at the end should work. What is the reasoning here? -- blu There are two rules in life: Rule 1- Don''t tell people everything you know ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
Brian Utterback writes:> So, two comments: > > 1. This is a case where a more general error message would probably > have been more helpful than the more specific ones.True.> 2. Why can''t they be combined? If the data recording actions are not > after a speculate, I don''t even see how they are related. I could see > if the commit went off into some other part of the dtrace code and the > rest of the actions were not executed that having the commit be first > would be a problem, but then a commit at the end should work. What is > the reasoning here?I think dtrace is exposing a little internal architecture here. A rule that does a commit() has special properties because it needs to synchronize where those just printing into a speculation do not. You can only commit once, no matter how many CPUs there are. It''s simple to work around, though. Just copy the clause into two pieces. Delete the "commit(...);" from the first one, and the "speculate(...);" and printing from the second. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
On Tue, Sep 02, 2008 at 02:30:27PM -0400, James Carlson wrote:> Brian Utterback writes: > > So, two comments: > > > > 1. This is a case where a more general error message would probably > > have been more helpful than the more specific ones. > > True. > > > 2. Why can''t they be combined? If the data recording actions are not > > after a speculate, I don''t even see how they are related. I could see > > if the commit went off into some other part of the dtrace code and the > > rest of the actions were not executed that having the commit be first > > would be a problem, but then a commit at the end should work. What is > > the reasoning here? > > I think dtrace is exposing a little internal architecture here. A > rule that does a commit() has special properties because it needs to > synchronize where those just printing into a speculation do not. You > can only commit once, no matter how many CPUs there are.The other problem is that commit() writes a potentially huge amount of data into the main buffer. It would complicate the code substantially to allow you to commit() and record data in the same enabling. The error message could be better; "enablings cannot have both commit() and data-recording actions" or something. File a bug.> It''s simple to work around, though. Just copy the clause into two > pieces. Delete the "commit(...);" from the first one, and the > "speculate(...);" and printing from the second.Indeed. Cheers, - jonathan