dtrace discuss - Jun 2010 - Old doc bug 6207856 and new bug (6958434)

I filed the following bug yesterday:

6958434 Table 25-2 missing two probes

which is related to:

6207856 Line is repeated in table 25-2

Filing a third bug against table 25-1 seemed silly (probes not listed in
order). I''d like to set both tables straight: order the probes, add the
missing ones, and remove the duplicate noted in 6207856. Bugster says a fix
is in place for 6207856 but I gather it''s fallen through the cracks.

Michael

-- 
Michael Ernest
Inkling Research, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20100604/072f7d4f/attachment.html>

After a deeper review of the tables in this section of wiki, I noticed the
following more persnickety elements:

The descriptions for the probes exec-failure and exec-success state that they
fire "only after the exec probe has fired in the same thread." I am
not aware of a case where one probe firing is contingent on another firing.
It''s certainly not common, in any event.

In general it seems difficult to state, without ambiguity, the order in which
two or more probes would fire if all were invoked, without either a) repeating
the "if invoked" business [i]ad nauseam[/i]; or b) implying a
lock-step relationship.

It seems to me an ordering condition like "only after" or
"immediately before" should only apply when describing a
probe''s immediate relationship to the event it traces. When applied to
the order of two or more probes, it allows for doubt in a close reading.

I don''t have a completely satisfying suggestion but the term
"follows" seems to help. The sentence:

The exec-failure probe fires only after the exec probe has fired in the same
thread.

would be clearer as

The exec-failure probe fires some time after the exec probe, assuming both are
invoked.

The sense of indefinite time used to describe the exec probe makes sense.
Readers who need to determine how long is "some time" can go to the
source; all others can live blithely in the mist that separates the description
from the implementation itself.

Other typos:

-> In Table 25-1, the entry for the signal-clear probe points to
sigtimedwait(3RT) and sigtimedwait(3RT).

The correct library is 3C.

-> In Table 25-1, the entry for the signal-send probe states "[t]he
lwpsinfo_t and psinfo_t of the receiving process and thread are in args[0] and
args[1], respectively."

"process and thread" should be "thread and process"

I propose to make these corrections in addition to the ones noted above if there
are no objections.
-- 
This message posted from opensolaris.org