The iofunc_ocb_t OCB structure

The OCB structure contains information used to track client access to a particular service offered by a resource manager, on a per-open or per-file-descriptor basis. What this means is that when a client performs an open() call and gets back a file descriptor (as opposed to an error indication), the resource manager will have created an OCB and associated it with the client. This OCB will be around for as long as the client has the file descriptor open.

Effectively, the OCB and the file descriptor are a matched pair. Whenever the client calls an I/O function, the resource manager library will automatically associate the OCB, and pass it along with the message to the I/O function specified by the I/O function table entry. This is why the I/O functions all had the ocb parameter passed to them. Finally, the client will close the file descriptor (via close()), which will cause the resource manager to dissociate the OCB from the file descriptor and client.

Note that the client's dup() function simply increments a reference count. In this case, the OCB gets dissociated from the file descriptor and client only when the reference count reaches zero (i.e., when the same number of close()s have been called as open() and dup()s.)

As you might suspect, the OCB contains things that are important on a per-open or per-file-descriptor basis. For a look at what's in this structure, see iofunc_ocb_t in the C Library Reference. If you wish to store additional data along with the normal OCB, rest assured that you can extend the OCB. We'll discuss this in the Extending the OCB section.

The offset member

The offset field is, to say the least, interesting. Depending on what preprocessor flags you've set, you may get different layouts for the offset area. But don't worry too much about the implementation—all offsets are 64-bit, of type off_t, and the platform knows how to deal with 64-bit quantities.