Langue: en

Version: 59107 (mandriva - 22/10/07)

Section: 2 (Appels système)


tsend, trecv - Send and receive LAM transport messages.


 #include <net.h>
 int tsend (struct nmsg *header);
 int trecv (struct nmsg *header);


subroutine TSND (nnode, nevent, ntype, nlength, nflags, ndata, ndsize, nmsg, ierror)
subroutine TRCV (nevent, ntype, nlength, nflags, ndata, ndsize, nmsg, ierror)
integer nnode, nevent, ntype, nlength, nflags, ndata(*), ndsize, nmsg(*), ierror


These transport message-passing routines add flow control to the network routines, nsend(2) and nrecv(2), and enable multiple processes to send multi-packet messages to a receiver using the same event and type while maintaining the atomicity of the messages. The sending process sends a "ready-to-send" message to the receiver and blocks until the receiving process signals that it is ready. The receiver returns to the sender a new event, its process ID negated, to be used in the transfer of the body of the message. The introduction of the second event allows multi-packet messages, using the same event and destined to the same node, to be received with no mixing up of packets. The transport routines are also typically used while developing and debugging applications. Naturally, they have higher overhead than their network counterparts.

The transport routines overcome the basic danger of LAM network message-passing - the lack of strong synchronization. A sending process can transmit a message that may never be received due to programming error or deadlock. This message will never be dropped or timed out. Some LAM process will always be stuck with it, waiting for a synchronizing drecv(2) or nrecv(2) that will never happen. If that unfortunate process is a buffer, it can be located by the user and swept clean (see sweep(1)). However, if the process is a link proprietor, the link is henceforth plugged and useless.

The transport routines solve this problem by causing the sending process to block until it receives a "ready-to-receive" protocol message from the receiving process. If due to a programming error there is no receiving process at the other end, the "ready-to-send" message is guaranteed not to plug a link proprietor. The second advantage in this case is that the sender is stopped from flooding the system with messages that no receiver will consume. After the pre-synchronizing exchange, the network routines are invoked and the message is transmitted.

Use of the network message structure passed to tsend() and trecv() is the same as described under nsend(2).


dsend(2), nsend(2)