Documentation Archive Developer
ADC Home > Reference Library > Reference > Mac OS X > Mac OS X Man Pages


This document is a Mac OS X manual page. Manual pages are a command-line technology for providing documentation. You can view these manual pages locally using the man(1) command. These manual pages come from many different sources, and thus, have a variety of writing styles.

For more information about the manual page format, see the manual page for manpages(5).

notify(3)                BSD Library Functions Manual                notify(3)

     notify_post, notify_register_check, notify_register_signal,
     notify_register_mach_port, notify_register_file_descriptor, notify_check,
     notify_get_state, notify_set_state, notify_cancel -- event distribution

     #include <notify.h>

     notify_post(const char *name);

     notify_register_check(const char *name, int *out_token);

     notify_register_signal(const char *name, int sig, int *out_token);

     notify_register_mach_port(const char *name, mach_port_t *notify_port, int flags, int *out_token);

     notify_register_file_descriptor(const char *name, int *notify_fd, int flags, int *out_token);

     notify_check(int token, int *check);

     notify_set_state(int token, uint64_t state);

     notify_get_state(int token, uint64_t *state);

     notify_cancel(int token);

     These routines allow processes to exchange stateless notification events.

     Notifications are associated with names in a namespace shared by all
     clients of the system.  Clients may post notifications for names, and may
     monitor names for posted notifications.  Clients may request notification
     delivery by a number of different methods.

     Clients desiring to monitor names in the notification system must regis-ter register
     ter with the system, providing a name and other information required for
     the desired notification delivery method.  Clients are given an integer
     token representing the registration.

     The kernel provides limitied queues for mach message and file descriptor
     messages.  It is important to make sure that clients read mach ports and
     file descriptors frequently to prevent messages from being lost due to
     resource limitations.  Clients that use signal-based notification should
     be aware that signals are not delivered to a process while it is running
     in a signal handler.  This may affect the delivery of signals in close

     Notifications may be coalesced in some cases.  Multiple events posted for
     a name in rapid succession may result in a single notification sent to
     clients registered for notification for that name.  Clients checking for
     changes using the notify_check() routine cannot determine if more than
     one event has been posted since a previous call to notify_check() for
     that name.

     "False positives" may occur in notify_check() when used with a token gen-erated generated
     erated by notify_register_check() due to implementation constraints.
     This behavior may vary in future releases.

     This routine causes the system to send a notification for the given name
     to all clients that have registered for notifications of this name.  This
     is the only API required for an appication that only produces notifica-tions. notifications.

     Registers for passive notification for the given name.  The routine gen-erates generates
     erates a token that may be used with the notify_check() routine to check
     if any notifications have been posted for the name.  The check is imple-mented implemented
     mented using a shared memory scheme, making the check very fast and effi-cient. efficient.
     cient.  The implementation has a limited amount of shared memory, so
     developers are encouraged to use this mechanism sparingly.  It is also
     important to release the resources consumed by a registration with
     notify_cancel() when they are no longer required by the application.

     registers a client for notification delivery via a signal.  This fits
     well with the design of many UNIX daemons that use a signal such as
     SIGHUP to reinitialize of reset internal state information.  Clients may
     use the registration token generated by this routine to check for notifi-cations notifications
     cations using notify_check().  This allows the application to determine
     if a signal was received as the result of a notification, or is the sig-nal signal
     nal was generated by some other source.  It also permits the application
     that registers for signal notification for multiple names to determine
     which name was associated with the notification.

     registers a client for notification delivery via mach messaging.  Notifi-cations Notifications
     cations are delivered by an empty message sent to a mach port.  By
     default, a new port is created by a call to this routine.  A mach port
     previously created by a call to this routine may be used for notifica-tions notifications
     tions if a pointer to that port is passed in to the routine and
     NOTIFY_REUSE is set in the flags parameter.  The notification service
     must be able to extract send rights to the port.

     Note that the kernel limits the size of the message queue for any port.
     If it is important that notifications should not be lost due to queue
     overflow, clients should service messages quickly, and be cautious in
     using the same port for notifications for more than one name.

     A notification message has an empty message body.  The msgh_id field in
     the mach message header will have the value of the notification token.
     If a port is reused for multiple notification registrations, the msgh_id
     value may be used to determine which name generated the notification.

     Register for notification by a write to a file descriptor.

     By default, a new file descriptor is created and a pointer to it is
     returned as the value of the "notify_fd" parameter.  A file descriptor
     created by a previous call to this routine may be used for notifications
     if a pointer to that file descriptor is passed in to the routine and
     NOTIFY_REUSE is set in the flags parameter.

     Note that the kernel limits the buffer space for queued writes on a file
     descriptor.  If it is important that notifications should not be lost due
     to queue overflow, clients should service messages quickly, and be cau-tious cautious
     tious in using the same file descriptor for notifications for more than
     one name.

     Notifications are delivered by an integer value written to the file
     descriptor.  The value will match the notification token for which the
     notification was generated.

     Checks if any notifications have been posted for a name.  The output
     parameter "check" is set to 0 for false, 1 for true.  A true indication
     is returned the first time notify_check is called for a token.  Subse-quent Subsequent
     quent calls give a true indication when notifications have been posted
     for the name associated with the notification token.

     notify_check() may be used with any notification token produced by any of
     the notification registration routines.  A fast check based on a shared
     memory implementation is used when the token was generated by
     notify_register_check().  Other tokens are checked by a call to the noti-fication notification
     fication server.

     Set a 64-bit unsigned integer variable associated with a token.

     Starting with Mac OS X 10.5, each registered notification key has an
     associated 64-bit integer variable, which may be set using this routine
     and examined using the notify_get_state() routine.  The state variable is
     free to be used by clients of the notification API.  It may be used to
     synchronize state information between cooperating processes or threads.

     Get the 64-bit unsigned integer value associated with a token.  The
     default value of a state variable is zero.

     Cancel notification and free resources associated with a notification
     token.  Mach ports and file descriptor associated with a token are
     released (deallocated or closed) when all registration tokens associated
     with the port or file descriptor have been cancelled.

     Names in the namespace must be NULL-terminated.  Names should be encoded
     as UTF-8 strings.

     The namespace supported by the system is unstructured, but users of this
     API are highly encouraged to follow the reverse-ICANN domain name conven-tion convention
     tion used for Java package names and for System Preferences on Mac OS X.
     For example, "com.mydomain.example.event".

     Apple Computer reserves the portion of the namespace prefixed by
     "".  This policy is not enforced in the current implementation,
     but may be in the future.

     Third party developers are encouraged to choose a prefix for names that
     will avoid conflicts in the shared namespace.

     The portion of the namespece prefixed by the string "self." is set aside
     for private use by applications.  That is, each client may use that part
     of the namespace for intra-process notifications.  These notifications
     are private to each individual process and are not propagated between

     A notification producer.

         #include <notify.h>


     A client using notify_check() to determine when to invalidate a cache.

         #include <stdio.h>
         #include <stdlib.h>
         #include <notify.h>

         main(int argc, char *argv[])
             int status, token, check;

             status = notify_register_check("", &token);
             if (status != NOTIFY_STATUS_OK)
                fprintf(stderr, "registration failed (%u)\n", status);



             status = notify_check(token, &check);
             if ((status == NOTIFY_STATUS_OK) && (check != 0))
                /* An update has occurred - invalidate the cache */


     A client using file descriptor notifications.

         #include <stdio.h>
         #include <stdlib.h>
         #include <string.h>
         #include <errno.h>
         #include <sys/types.h>
         #include <sys/time.h>
         #include <unistd.h>
         #include <notify.h>

         main(int argc, char *argv[])
             int nf, status, rtoken, qtoken, t;
             fd_set readfds;

             status = notify_register_file_descriptor("",
                &nf, 0, &rtoken);
             if (status != NOTIFY_STATUS_OK)
                fprintf(stderr, "registration failed (%u)\n", status);

             status = notify_register_file_descriptor("",
                 &nf, NOTIFY_REUSE, &qtoken);
             if (status != NOTIFY_STATUS_OK)
                fprintf(stderr, "registration failed (%u)\n", status);

             FD_SET(nf, &readfds);

             for (;;)
                status = select(nf+1, &readfds, NULL, NULL, NULL);
                if (status <= 0) continue;
                if (!FD_ISSET(nf, &readfds)) continue;

                status = read(nf, &t, sizeof(int));
                if (status < 0)

                if (t == rtoken) printf("random event\n");
                else if (t == qtoken) break;

             printf("shutting down\n");

     These functions first appeared in Mac OS X 10.3.

     read(2), select(2), signal(3)

Mac OS X                        March 19, 2003                        Mac OS X