The first argument to msgsnd is our queue identifier, returned by a previous
call to msgget. The second argument, msgp, is a pointer to our
redeclared and loaded message buffer. The msgsz argument contains the size
of the message in bytes, excluding the length of the message type (4 byte long).

The msgflg argument can be set to 0 (ignored), or:

IPC_NOWAIT

If the message queue is full, then the message is not written to the
queue, and control is returned to the calling process. If not
specified, then the calling process will suspend (block) until the
message can be written.

This small function attempts to send the message residing at the passed address (qbuf)
to the message queue designated by the passed queue identifier (qid). Here is
a sample code snippet utilizing the two wrapper functions we have developed so far:

After creating/opening our message queue, we proceed to load up the message buffer
with test data (note the lack of character data to illustrate our point about
sending binary information). A quick call to send_message merrily
distributes our message out to the message queue.

Now that we have a message on our queue, try the ipcs command to view the status
of your queue. Now let's turn the discussion to actually retrieving the message from
the queue. To do this, you use the msgrcv() system call:

Obviously, the first argument is used to specify the queue to be used during the message
retrieval process (should have been returned by an earlier call to msgget). The
second argument (msgp) represents the address of a message buffer variable to store
the retrieved message at. The third argument (msgsz) represents the size of the
message buffer structure, excluding the length of the mtype member. Once again,
this can easily be calculated as:

msgsz = sizeof(struct mymsgbuf) - sizeof(long);

The fourth argument (mtype) specifies the type of message to retrieve from
the queue. The kernel will search the queue for the oldest message having a matching type,
and will return a copy of it in the address pointed to by the msgp argument. One
special case exists. If the mtype argument is passed with a value of zero, then
the oldest message on the queue is returned, regardless of type.

If IPC_NOWAIT is passed as a flag, and no messages are available, the call
returns ENOMSG to the calling process. Otherwise, the calling process blocks until a message
arrives in the queue that satisfies the msgrcv() parameters. If the queue is deleted
while a client is waiting on a message, EIDRM is returned. EINTR is returned if a signal is
caught while the process is in the middle of blocking, and waiting for a message to arrive.

Let's examine a quick wrapper function for retrieving a message from our queue:

After successfully retrieving a message from the queue, the message entry within the queue
is destroyed.

The MSG_NOERROR bit in the msgflg argument provides some additional capabilities.
If the size of the physical message data is greater than msgsz, and MSG_NOERROR
is asserted, then the message is truncated, and only msgsz bytes are returned. Normally,
the msgrcv() system call returns -1 (E2BIG), and the message will remain on the
queue for later retrieval. This behavior can used to create another wrapper function, which will allow
us to ``peek'' inside the queue, to see if a message has arrived that satisfies our request:

Above, you will notice the lack of a buffer address and a length. In this particular
case, we want the call to fail. However, we check for the return of E2BIG which
indicates that a message does exist which matches our requested type. The wrapper function
returns TRUE on success, FALSE otherwise. Also note the use of the IPC_NOWAIT
flag, which prevents the blocking behavior described earlier.