resmgr_msgreply()

Reply to a client with a message, endian-swapping if required

Synopsis:

#include <sys/iofunc.h>
#include <sys/resmgr.h>

int resmgr_msgreply( resmgr_context_t *ctp,
                     void *ptr,
                     size_t len );

Arguments:

ctp: A pointer to a resmgr_context_t structure that the resource-manager library uses to pass context information between functions. This function extracts the rcvid, status, info.flags, and possibly extra->xendian fields from this structure, which means the function is not safe to use in certain situations (see below).
ptr: A pointer that contains the message that you want to reply with.
len: The number of bytes that you want to write.

Library:

libc

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

Description:

The resmgr_msgreply() function replies with a message to the thread identified by ctp->rcvid. It's a wrapper over MsgReplyv() that endian-swaps standard I/O message types for use over Qnet. If Qnet isn't in use, or no endian-swapping is necessary, it simply invokes MsgReplyv(). The resmgr_msgreplyv() function is similar to resmgr_msgreply() but takes an array of message buffers.

Note:

Don't use resmgr_msgreply() for delayed replies. This function may modify the contents of the reply buffer based on the info.flags and extra->xendian fields of the ctp structure, before using the rcvid and status fields when calling MsgReplyv(). If you then use this structure in other function calls, you could end up with the wrong endianness when passing data across heterogeneous machines. For delayed replies, you should instead call MsgReply() or MsgReplyv() directly.

You should use resmgr_msgreply() only within the context of an IO handler for the current message.

This function is called by the server to reply back to the client. The client thread must already be in the REPLY state, and 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.

Note: You can fill the client's reply buffer as data becomes available by using resmgr_msgwrite() and resmgr_msgwritev(); however, you'll need to call resmgr_msgreply() or resmgr_msgreplyv() at some point to unblock the client.

If the function succeeds, 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.

The data transfer occurs immediately, and the replying thread doesn't block. 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.

Returns:

If an error occurs, -1 is returned and errno is set.

Errors:

EDEADLK: 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().
EENDIAN: The message type wasn't recognized and therefore couldn't be endian-swapped.
EFAULT: A fault occurred in the sender's address space when a server tried to access the sender's return message buffers.
ENOREMOTE: The reply has to go across the network, and Qnet isn't running.
ESRCH: The thread indicated by rcvid doesn't exist, or is no longer REPLY-blocked on the channel, or the connection was detached.
ESRVRFAULT: A fault occurred when the kernel tried to access the buffers provided.

Classification:

QNX Neutrino

Safety:
Cancellation point	No
Interrupt handler	No
Signal handler	Yes
Thread	Yes