resmgr_detach(), resmgr_detach_ctp()

Arguments:

dpp

A dispatch handle created by a successful call to dispatch_create().

ctp

(resmgr_detach_ctp() only) A pointer to a resmgr_context_t structure that the resource-manager library uses to pass context information between functions, or NULL (see below).

id

The link ID that resmgr_attach() returned.

flags

Flags that affect the operation. The possible flags (defined in <sys/dispatch.h> and <sys/resmgr.h>) are:

• _RESMGR_DETACH_ALL — detach the name from the namespace and invalidate all open bindings.
• _RESMGR_DETACH_CLOSE — close all bindings when detaching.
• _RESMGR_DETACH_PATHNAME — detach only the name from the namespace, leaving existing bindings intact. This option is useful when you're unlinking a file or device, and you want to remove the name, but you want processes with open files to continue to use it until they close.

Library:

libc

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

Description:

The resmgr_detach() and resmgr_detach_ctp() functions remove the pathname indicated by id from the pathname space of context dpp. The resmgr_detach_ctp() function includes a pointer to the resmgr_context_t structure, which lets the function get information about the link currently being operated on. This latter function can be used only if the _RESMGR_FLAG_DETACH_CTP flag was passed in to resmgr_attach().

Blocking states

These functions block until the RESMGR_HANDLE_T that was passed to the corresponding resmgr_attach() isn't being used in any connection function.

The effect that this has on servers is generally minimal. You should follow the following precautions to prevent potential deadlock situations:

• If you're using the RESMGR_HANDLE_T as an attribute, and that attribute is locked in any of the connection callouts (i.e., open, unlink, mount, etc.), then should unlock it before calling resmgr_detach*(). This allows any pending connection requests to complete before they're consequently invalidated.
  Note:

  If you call resmgr_detach*() from within a connection function, then the internal reference counting takes this into account and the server doesn't deadlock.
• If two or more resmgr_detach*() requests come in simultaneously, only one of the requests is served. The superfluous request will return with an error of -1 and errno set to ENOENT to indicate that the detachment process has already begun, and the entry is now invalid. If dynamically allocated, you should release RESMGR_HANDLE_T only after a successful return from resmgr_detach*().
• If resmgr_detach()* is called and an existing client connection is established, then the I/O callout table is redirected for that client connection. The client will receive an error of EBADF when it uses the fd associated with that connection.

Returns:

0

Success.

-1

An error occurred (errno is set).

Errors:

EINVAL

The id was never attached with resmgr_attach().

ENOENT

A previous detachment request is in progress, or the id has already been detached.

Examples:

#include <sys/dispatch.h>
#include <stdio.h>
#include <stdlib.h>

int main( int argc, char **argv ) {
   dispatch_t  *dpp;
   int         id;

   if ( (dpp = dispatch_create()) == NULL ) {
      fprintf( stderr, "%s: Unable to allocate \
               dispatch handle.\n",argv[0] );
      return EXIT_FAILURE;
   }

   id = resmgr_attach ( … );

   …

   if ( resmgr_detach( dpp, id, 0) == -1 ) {
      fprintf( stderr, "Failed to remove pathname \
               from the pathname space.\n" );
      return EXIT_FAILURE;
}

For examples using the dispatch interface, see dispatch_create(), message_attach(), resmgr_attach(), and thread_pool_create().

Classification:

QNX OS