next up previous contents index
Next: Participant Library Up: Message Library Previous: Manipulation Operations

Usage Rules

 

The x-kernel coding conventions dictate that messages should be destroyed by the same entity that originally constructed them. Thus, the ethernet driver is responsible for destroying messages after successfully delivering them upward, and the top-level protocols that interface to user functions should destroy messages that have been successfully delivered to their destination.

When a protocol passes a message to an adjacent protocol (via xPush, xDemux, etc.) its view of the message becomes invalid. The contents of the message after such an operation depend on which lower headers were pushed onto it. Should a protocol want to keep a reference to the message (e.g., so it can later retransmit it) it must explicitly save a copy using either the msgAssign or the msgConstructCopy operation before passing the message on to another protocol.

Note that although a protocol which constructs a message invalidates its view of the message by performing a UPI operation involving that message, it is still responsible for destroying the message.

The stack ownership is a hidden variable in the message library implementation that affects whether or not storage is automatically allocated on msgPush operations. The stack ownership is affected by several message library operations, particularly msgAssign, msgJoin, msgPeek, and msgConstructCopy. The user is referred to the source code for the details of the ownership rules.

Message attributes passed between protocols should consist of exportable data, i.e., not pointers. Adherence to this convention will ensure that the protocol can be in used in a multi-address space environment.



Larry Peterson
Tue Jul 1 14:50:34 MST 1997