resmgr_msgreply()

Reply to client with a message

Synopsis:

#include <sys/resmgr.h>

int resmgr_msgreply( resmgr_context_t *ctp,
                     void *ptr,
                     int 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 from this structure.

len

The number of bytes that you want to write. This function doesn't let you write past the end of the sender's buffer; it returns the number of bytes actually written.

ptr

A pointer that contains the message that you want to reply with.

Library:

libc

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

Description:

The purpose of using resmgr_msgreply(), instead of using MsgReply() is that resmgr_msgreply() supports endian-swapping of standard resmgr message types, whereas MsgReply() doesn't. The function resmgr_msgreply() is a cover for msgreply() and performs the exact same functionality. The resmgr_msgreply() kernel call replies with a message to the thread identified by ctp->rcvid. This function is called by the server to reply back to the client. The client thread must already be in state REPLY. 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.

---

You can fill the client's reply buffer as data becomes available by using resmgr_msgwrite() and resmgr_msgwritev(); however, you'll need to use the resmgr_msgpeply() or resmgr_msgpeplyv() at some point to unblock the client. The function whose name contains the “v” suffix is the multipart message version for the function.

---

The data is taken from the array of message buffers pointed to by ptr. The number of elements in this array is given by len. The size of the message is the sum of the sizes of each buffer.

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.

Blocking states

None. In the network case, lower priority threads may run.

Returns:

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

Errors:

EFAULT

A fault occurred in the sender's address space when a server tried to access the sender's return message buffers.

ESRCH

The thread indicated by rcvid doesn't exist, or is no longer REPLY-blocked on the channel, or the connection is detached.

ESRVRFAULT

A fault occurred when the kernel tried to access the buffers provided.

Classification:

QNX Neutrino

See also:

resmgr_msgwrite(), resmgr_msgwritev(), resmgr_context_t, resmgr_msgread(), resmgr_msgreadv(), resmgr_msgwritev(), MsgWrite(), MsgReplyv(), MsgReceive(), MsgReceivev(), MsgReply(), MsgSend(), MsgSendv()

“Layers in a resource manager” in the Bones of a Resource Manager chapter of Writing a Resource Manager

Resource Managers chapter of Getting Started with QNX Neutrino