MsgReply(), MsgReply_r()

Reply with a message


#include <sys/neutrino.h>

int MsgReply( int rcvid,
              long status,
              const void* msg,
              size_t bytes );

int MsgReply_r( int rcvid,
                long status,
                const void* msg,
                size_t bytes );


The receive ID that MsgReceive*() returned when you received the message.
The status to use when unblocking the client's MsgSend*() call in the rcvid thread.
Note: The MsgSend*_r() functions return negative errno values to indicate failure, so you shouldn't pass a negative value for the status to MsgReply*(), because the MsgSend*_r() functions could interpret it as an error code. If you wish to indicate an error, call MsgError().
A pointer to a buffer that contains the message that you want to reply with.
The size of the message, in bytes. This number must not exceed SSIZE_MAX, or the function will behave unpredictably.



Use the -l c option to qcc to link against this library. This library is usually included automatically.


The MsgReply() and MsgReply_r() kernel calls reply with a message to the thread identified by rcvid. The thread being replied to must be in the REPLY-blocked state. Any thread in the receiving process is free to reply to the message, however, it may be replied to only once for each receive.

These functions are identical except in the way they indicate errors. See the Returns section for details.

The MsgSend*() in the rcvid thread unblocks with a return value of status.

The number of bytes transferred is the minimum of that specified by both the replier and the sender. The reply data isn't allowed to overflow the reply buffer area provided by the sender.

In the local case, the data transfer occurs immediately, and the replying task doesn't block (see “Blocking states,” below). There's no need to reply to received messages in any particular order, but you must eventually reply to each message to allow the sending thread(s) to continue execution.

Blocking states

None for the local case. In the network case:

The calling thread is waiting for a network operation to complete. The calling thread is marked as REPLY-blocked on itself (the same process ID as the thread making the call).

Native networking

The MsgReply() function has increased latency when it's used to communicate across a network—the server is now writing data to its local, which may need to communicate with the client's to actually transfer the data.


The only difference between the MsgReply() and MsgReply_r() functions is the way they indicate errors:

If successful, this function returns EOK. If an error occurs, it returns -1 and sets errno.
If successful, this function returns EOK. If an error occurs, it may return the negative of any value from the Errors section. This function does NOT set errno, even on success.


A deadlock occurred. You can avoid a deadlock by setting the _NTO_CHF_MSG_PAUSING flag when you create a channel; for more information, see ChannelCreate() and MsgPause().
A fault occurred in the sender's address space when a server tried to access the sender's return message buffers.
The reply has to go across the network, and Qnet isn't running.
The thread indicated by rcvid doesn't exist, or is no longer REPLY-blocked on the channel, or the connection was detached.
A fault occurred when the kernel tried to access the buffers provided.
A kernel timeout unblocked the call. See TimerTimeout().


QNX Neutrino

Cancellation point No
Interrupt handler No
Signal handler Yes
Thread Yes


The maximum size for a one-part message depends on the architecture: