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:
- rcvid
- 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).
- info
- 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.
- msg
- 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.
- dpp
- 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.
- id
- 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.
- msg_max_size
- 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.
- status
- 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).
- offset
- 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).
- size
- 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).
- iov
- 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).