This version of this document is no longer maintained. For the latest documentation, see http://www.qnx.com/developers/docs.

resmgr_detach()

Remove a pathname from the pathname space

Synopsis:

#include <sys/iofunc.h>
#include <sys/dispatch.h>

int resmgr_detach( dispatch_t * dpp,
                   int id,
                   unsigned flags );

Arguments:

dpp

A dispatch handle created by dispatch_create().

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_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() function removes pathname id from the pathname space of context dpp.

Blocking states

The resmgr_detach() function blocks until the RESMGR_HANDLE_T, that's 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.

  ---

  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 Neutrino

See also:

dispatch_create(), resmgr_attach()

"Writing a Resource Manager" chapter of the Programmer's Guide.