Connect message types

QNX SDP8.0Writing a Resource ManagerDeveloper

Let's look at the general case for the io_open handler—it doesn't always correspond to the client's open() call! For example, let's consider the stat() and access() client function calls.

_IO_CONNECT_COMBINE_CLOSE

For a stat() client call, we essentially perform the sequence open(), fstat(), and close(). Note that if we actually did that, three messages would be required. For performance reasons, we implement the stat() function as one single combine message:
Client call:
stat()
Message(s):
_IO_CONNECT_COMBINE_CLOSE , _IO_STAT
Callouts:
io_open, io_lock_ocb, io_stat, io_unlock_ocb, io_close

The _IO_CONNECT_COMBINE_CLOSE message causes the io_open handler to be called. It then implicitly (at the end of processing for the combine message) causes the io_close_ocb handler to be called.

Optimizing the handling of _IO_CONNECT_COMBINE_CLOSE messages

The connect-combine-close message handler is an optional callout that can be used to optimize the handling of common POSIX operations. It provides resource managers with a faster way to handle the following operations:
  • stat()/lstat()
  • pathconf()
  • chmod()
  • chown()
  • utime()/utime64()

Normally, to perform one of the above POSIX operations, the steps include creating an Open Control Block (OCB), performing a resource manager callout (eg. stat), and then closing the OCB (typically via close_dup and close_ocb). To save time, this handler combines the (open, specific callout, close) sequence, so that a single callout processes the entire operation without creating an OCB.

Therefore, the connect-combine-close messsage handler contains two messages instead of one (as a regular message handler would) and uses the structures shown in the following prototype: 
int (*combo) (resmgr_context_t *ctp,
              io_open_t *msg1,
              RESMGR_HANDLE_T *handle,
              _resmgr_combomsgs_t *msg2)
where:
  • The io_open_t structure contains the open message with a path to resolve, if any.
  • The _resmgr_combomsgs_t structure contains the specific operation to process (eg. stat()).
Messages:
_IO_STAT, _IO_UTIME, _IO_UTIME64, _IO_PATHCONF, _IO_CHMOD, _IO_CHOWN
Returns:
_RESMGR_DEFAULT
The framework returns to its default method of handling connect-combine-close messages (eg. open, specific callout, close).
Otherwise, the connect-combine-close message handler returns the expected return value, as if from a regular resource manager callout.

_IO_CONNECT_COMBINE

For the access() function, the client's C library will open a connection to the resource manager and perform a stat() call. Then, based on the results of the stat() call, the client's C library access() may perform an optional devctl() to get more information. In any event, because access() opened the device, it must also call close() to close it:

Client call:
access()
Message(s):
_IO_CONNECT_COMBINE , _IO_STAT, _IO_DEVCTL (optional), _IO_CLOSE
Callouts:
io_open, io_lock_ocb, io_stat, io_unlock_ocb, io_lock_ocb (optional), io_devctl (optional), io_unlock_ocb (optional), io_close
Notice how the access() function opened the pathname/device—it sent it an _IO_CONNECT_COMBINE message along with the _IO_STAT message. This creates an OCB (when the io_open handler is called), locks the associated attribute structure (via io_lock_ocb), performs the stat (io_stat), and then unlocks the attributes structure (io_unlock_ocb). Note that we don't implicitly close the OCB—this is left for a later, explicit, message. Contrast this handling with that of the plain stat() above.
Note:
Note that close() (not ConnectDetach()) must follow the message if we send a custom _IO_CONNECT_COMBINE message, even when MsgSend() returns an error.
Page updated: