<ahref="#pub-methods">Public Member Functions</a>|
<ahref="classcrashpad_1_1NotifyServer_1_1DefaultInterface-members.html">List of all members</a></div>
<divclass="headertitle">
<divclass="title">crashpad::NotifyServer::DefaultInterface Class Reference</div></div>
</div><!--header-->
<divclass="contents">
<p>A concrete implementation of <aclass="el"href="classcrashpad_1_1NotifyServer_1_1Interface.html"title="An interface that the different request messages that are a part of the notify Mach subsystem can be ...">Interface</a> that provides a default behavior for all <code>notify</code> routines.
<areahref="classcrashpad_1_1NotifyServer_1_1Interface.html"title="An interface that the different request messages that are a part of the notify Mach subsystem can be ..."alt="crashpad::NotifyServer::Interface"shape="rect"coords="0,0,239,24"/>
<trclass="memdesc:a462b8fbfe77693bc77e4dc394d89398f"><tdclass="mdescLeft"> </td><tdclass="mdescRight">Handles port-deleted notifications sent by <code>mach_notify_port_deleted()</code>. <ahref="#a462b8fbfe77693bc77e4dc394d89398f">More...</a><br/></td></tr>
<trclass="memdesc:a26e577092f3d7289a950545319e29d7f"><tdclass="mdescLeft"> </td><tdclass="mdescRight">Handles port-destroyed notifications sent by <code>mach_notify_port_destroyed()</code>. <ahref="#a26e577092f3d7289a950545319e29d7f">More...</a><br/></td></tr>
<trclass="memdesc:aed9cb9e85f275edd5ee72eca34888188"><tdclass="mdescLeft"> </td><tdclass="mdescRight">Handles no-senders notifications sent by <code>mach_notify_no_senders()</code>. <ahref="#aed9cb9e85f275edd5ee72eca34888188">More...</a><br/></td></tr>
<trclass="memdesc:a3a5e82e6bd51eac1dbff7aac2c7b6bf4"><tdclass="mdescLeft"> </td><tdclass="mdescRight">Handles send-once notifications sent by <code>mach_notify_send_once()</code>. <ahref="#a3a5e82e6bd51eac1dbff7aac2c7b6bf4">More...</a><br/></td></tr>
<trclass="memdesc:a0373d989a72ee8c37ab4977f8ffb836a"><tdclass="mdescLeft"> </td><tdclass="mdescRight">Handles dead-name notifications sent by <code>mach_notify_dead_name()</code>. <ahref="#a0373d989a72ee8c37ab4977f8ffb836a">More...</a><br/></td></tr>
<divclass="textblock"><p>A concrete implementation of <aclass="el"href="classcrashpad_1_1NotifyServer_1_1Interface.html"title="An interface that the different request messages that are a part of the notify Mach subsystem can be ...">Interface</a> that provides a default behavior for all <code>notify</code> routines. </p>
<p>The Mach <code>notify</code> subsystem contains a collection of unrelated routines, and a single server would rarely need to implement all of them. To make it easier to use <aclass="el"href="classcrashpad_1_1NotifyServer.html"title="A server interface for the notify Mach subsystem. ">NotifyServer</a>, a server can inherit from <aclass="el"href="classcrashpad_1_1NotifyServer_1_1DefaultInterface.html"title="A concrete implementation of Interface that provides a default behavior for all notify routines...">DefaultInterface</a> instead of <aclass="el"href="classcrashpad_1_1NotifyServer_1_1Interface.html"title="An interface that the different request messages that are a part of the notify Mach subsystem can be ...">Interface</a>. Unless overridden, each routine in <aclass="el"href="classcrashpad_1_1NotifyServer_1_1DefaultInterface.html"title="A concrete implementation of Interface that provides a default behavior for all notify routines...">DefaultInterface</a> returns <code>MIG_BAD_ID</code> to indicate to the caller that the <code>notify</code> message was unexpected and not processed. </p>
</div><h2class="groupheader">Member Function Documentation</h2>
<p>Handles dead-name notifications sent by <code>mach_notify_dead_name()</code>. </p>
<p>A dead-name notification is generated when a port with a dead-name notification request is destroyed and the right becomes a dead name.</p>
<p>This behaves equivalently to a <code>do_mach_notify_dead_name()</code> function used with <code>notify_server()</code>.</p>
<dlclass="params"><dt>Parameters</dt><dd>
<tableclass="params">
<tr><tdclass="paramdir">[in]</td><tdclass="paramname">notify</td><td>The Mach port that the notification was sent to. </td></tr>
<tr><tdclass="paramdir">[in]</td><tdclass="paramname">name</td><td>The dead name. Although this is transferred as a <code>mach_port_name_t</code> and not a <code>mach_port_t</code>, the callee assumes an additional reference to this port when this method is called. See the note below. </td></tr>
<tr><tdclass="paramdir">[in]</td><tdclass="paramname">trailer</td><td>The trailer received with the notification message.</td></tr>
</table>
</dd>
</dl>
<dlclass="section note"><dt>Note</dt><dd>When a dead-name notification is generated, the user reference count of the dead name is incremented. A send right with one reference that becomes a dead name will have one dead-name reference, and the dead-name notification will add another dead-name reference, for a total of 2. <aclass="el"href="classcrashpad_1_1NotifyServer_1_1DefaultInterface.html#a0373d989a72ee8c37ab4977f8ffb836a"title="Handles dead-name notifications sent by mach_notify_dead_name(). ">DoMachNotifyDeadName()</a> implementations must take care to deallocate this extra reference. There is no <em>destroy_request</em> parameter to simplify this operation because dead-name notifications carry a port name only (<em>name</em> is of type <code>mach_port_name_t</code>) without transferring port rights, and are thus not complex Mach messages. </dd></dl>
<p>Handles no-senders notifications sent by <code>mach_notify_no_senders()</code>. </p>
<p>A no-senders notification is generated when a receive right with a no-senders notification request loses its last corresponding send right.</p>
<p>This behaves equivalently to a <code>do_mach_notify_no_senders()</code> function used with <code>notify_server()</code>.</p>
<dlclass="params"><dt>Parameters</dt><dd>
<tableclass="params">
<tr><tdclass="paramdir">[in]</td><tdclass="paramname">notify</td><td>The Mach port that the notification was sent to. </td></tr>
<tr><tdclass="paramdir">[in]</td><tdclass="paramname">mscount</td><td>The value of the sender-less port’s make-send count at the time the notification was generated. </td></tr>
<tr><tdclass="paramdir">[in]</td><tdclass="paramname">trailer</td><td>The trailer received with the notification message. </td></tr>
<p>Handles port-deleted notifications sent by <code>mach_notify_port_deleted()</code>. </p>
<p>A port-deleted notification is generated when a port with a dead-name notification request is destroyed and the port name becomes available for reuse.</p>
<p>This behaves equivalently to a <code>do_mach_notify_port_deleted()</code> function used with <code>notify_server()</code>.</p>
<dlclass="params"><dt>Parameters</dt><dd>
<tableclass="params">
<tr><tdclass="paramdir">[in]</td><tdclass="paramname">notify</td><td>The Mach port that the notification was sent to. </td></tr>
<tr><tdclass="paramdir">[in]</td><tdclass="paramname">name</td><td>The name that formerly referenced the deleted port. When this method is called, <em>name</em> no longer corresponds to the port that has been deleted, and may be reused for another purpose. </td></tr>
<tr><tdclass="paramdir">[in]</td><tdclass="paramname">trailer</td><td>The trailer received with the notification message. </td></tr>
<p>Handles port-destroyed notifications sent by <code>mach_notify_port_destroyed()</code>. </p>
<p>A port-destroyed notification is generated when a receive right with a port-destroyed notification request is destroyed. Rather than destroying the receive right, it is transferred via this notification’s <em>rights</em> parameter.</p>
<p>This behaves equivalently to a <code>do_mach_notify_port_destroyed()</code> function used with <code>notify_server()</code>.</p>
<dlclass="params"><dt>Parameters</dt><dd>
<tableclass="params">
<tr><tdclass="paramdir">[in]</td><tdclass="paramname">notify</td><td>The Mach port that the notification was sent to. </td></tr>
<tr><tdclass="paramdir">[in]</td><tdclass="paramname">rights</td><td>A receive right for the port that would have been destroyed. The callee takes ownership of this port, however, if the callee does not wish to take ownership, it may set <em>destroy_request</em> to <code>true</code>. </td></tr>
<tr><tdclass="paramdir">[in]</td><tdclass="paramname">trailer</td><td>The trailer received with the notification message. </td></tr>
<tr><tdclass="paramdir">[out]</td><tdclass="paramname">destroy_request</td><td><code>true</code> if the request message is to be destroyed even when this method returns success. See <aclass="el"href="classcrashpad_1_1MachMessageServer_1_1Interface.html"title="A Mach RPC callback interface, called by Run(). ">MachMessageServer::Interface</a>. </td></tr>
<p>Handles send-once notifications sent by <code>mach_notify_send_once()</code>. </p>
<p>A send-once notification is generated when a send-once right is destroyed without being used.</p>
<p>This behaves equivalently to a <code>do_mach_notify_send_once()</code> function used with <code>notify_server()</code>.</p>
<dlclass="params"><dt>Parameters</dt><dd>
<tableclass="params">
<tr><tdclass="paramdir">[in]</td><tdclass="paramname">notify</td><td>The Mach port that the notification was sent to. </td></tr>
<tr><tdclass="paramdir">[in]</td><tdclass="paramname">trailer</td><td>The trailer received with the notification message.</td></tr>
</table>
</dd>
</dl>
<dlclass="section note"><dt>Note</dt><dd>Unlike the other notifications in the <code>notify</code> subsystem, send-once notifications are not generated as a result of a notification request, but are generated any time a send-once right is destroyed rather than being used. The notification is sent via the send-once right to its receiver. These notifications are more useful for clients, not servers. Send-once notifications are normally handled by MIG-generated client routines, which make send-once rights for their reply ports and interpret send-once notifications as a signal that there will be no reply. Although not expected to be primarily useful for servers, this method is provided because send-once notifications are defined as a part of the <code>notify</code> subsystem. </dd></dl>
