how would those be implemented in practice? is it sufficient to add a couple of DTrace builtins, and if yes which are those?

The probe will separately keep state for each element being queued/dequeued (the probe with a given Qid will fire for every queue/dequeue event)

there is previous work done in this space (i.e. Dapper). The notion of spans with respect to the lifetime of particular RPCs and their hierarchical arrangement is worth generalising.

This should all be discussed in a separate section

It is unclear what probe names we should support for combinator (i.e. higher-level) wait probes. The example here assumes we could expose names such as

• "one": record data from the first wait probe that fires,
• "n": record data from the first n wait probes that fire (will need to decide on how to pass the value of n) ,
• "deadline": record data from all the waits until a timer expires,
• "condition": record data from the wait probes firing while condition is false
• "all": record data until the probed subsystem (NFS in this case) returns execution to some other subsystem. todo(lc525): figure out how to deal with asynchrony

This is very much an incomplete draft at the moment. Comments on the structure are welcome, but ideas or noticing potential risks/pitfalls are even better.

Please register with hypothes.is to comment on this document. A private group exists for editorial work.