Table D-4 describes the various ways ttsession checks for matches.
Table D-4 How ttsession Checks for Matches
Mechanism |
Description |
Match? |
---|---|---|
|
This type of addressing is "point-to-point" delivery -- the message is passed directly to the receiver. You cannot monitor point-to-point messages because registered patterns are never checked. |
No matching required. |
|
Scans list of static signatures (sig) that have same operation (op) and collects lists of observers and potential handlers. If the sig has no arguments and no contexts If sig prototype (number, type and mode of args) have different values If the sig contexts are a subset of the contexts in the message Saves information for any static observers that require queuing. Scans through dynamic patterns and adds to lists of observers and potential handlers. To form the lists, ttsession first uses the patterns with operations, then the patterns without operations. Checks reliability, states, class, address, handler, handler ptype, scope, object, otype, sender, sender_ptype, args, contexts. Delivers to observers first (because a handler can change state). Delivers to handler with best match -- if more than one handler equally "best" matches, the handler is arbitrarily chosen. |
=> Match => No Match => Match |
|
Checks whether the otype argument is filled in If sig has a different otype If sig has no otype & scope is different Otherwise, matches in the same manner as for |
=> No Match => No Match |