The resmgr_context_t internal context block

Finally, one data structure is used by the lowest layer of the library to keep track of information that it needs to know about. You should view the contents of this data structure as “read-only,” (except for the iov member).

Here's the data structure (from <sys/resmgr.h>):

typedef struct _resmgr_context {
  int                 rcvid;
  struct _msg_info    info;
  resmgr_iomsgs_t     *msg;
  dispatch_t          *dpp;
  int                 id;
  size_t              msg_max_size;
  long                status;
  size_t              offset;
  size_t              size;
  iov_t               iov [1];
} resmgr_context_t;

As with the other data structure examples, I've taken the liberty of deleting reserved fields.

Let's look at the contents:

The receive ID from the resource manager library's MsgReceivev() function call. Indicates who you should reply to (if you're going to do the reply yourself).
Contains the information structure returned by MsgReceivev() in the resource manager library's receive loop. Useful for getting information about the client, including things like the node descriptor, process ID, thread ID, and so on. See the documentation for MsgReceivev() for more details.
A pointer to a union of all possible message types. This isn't very useful to you, because each of your handler functions get passed the appropriate union member as their second parameter.
A pointer to the dispatch structure that you passed in to begin with. Again, not very useful to you, but obviously useful to the resource manager library.
The identifier for the mountpoint this message was meant for. When you did the resmgr_attach(), it returned a small integer ID. This ID is the value of the id member. Note that you'd most likely never use this parameter yourself, but would instead rely on the attributes structure passed to you in your open connect function handler.
This contains the msg_max_size that was passed in as the msg_max_size member of resmgr_attr_t (given to the resmgr_attach() function) so that the size, offset, and msg_max_size are all contained in one handy structure/location.
This is where your handler function places the result of the operation. Note that you should always use the macro _RESMGR_STATUS() to write this field. For example, if you're handling the connect message from an open(), and you're a read-only resource manager but the client wanted to open you for write, you'd return an EROFS errno via (typically) _RESMGR_STATUS (ctp, EROFS).
The current number of bytes into the client's message buffer. Only relevant to the base layer library when used with resmgr_msgreadv() with combine messages (see below).
This tells you how many bytes are valid in the message area that gets passed to your handler function. This number is important because it indicates if more data needs to be read from the client (for example, if not all of the client's data was read by the resource manager base library), or if storage needs to be allocated for a reply to the client (for example, to reply to the client's read() request).
The I/O Vector table where you can write your return values, if returning data. For example, when a client calls read() and your read-handling code is invoked, you may need to return data. This data can be set up in the iov array, and your read-handling code can then return something like _RESMGR_NPARTS (2) to indicate (in this example) that both iov [0] and iov [1] contain data to return to the client. Note that the iov member is defined as only having one element. However, you'll also notice that it's conveniently at the end of the structure. The actual number of elements in the iov array is defined by you when you set the nparts_max member of the control structure above (in the section resmgr_attr_t control structure, above).