<ahref="#pub-methods">Public Member Functions</a>|
<ahref="classcrashpad_1_1UniversalMachExcServer-members.html">List of all members</a></div>
<divclass="headertitle">
<divclass="title">crashpad::UniversalMachExcServer Class Reference<spanclass="mlabels"><spanclass="mlabel">final</span></span></div></div>
</div><!--header-->
<divclass="contents">
<p>A server interface for the <code>exc</code> and <code>mach_exc</code> Mach subsystems, unified to handle exceptions delivered to either subsystem, and simplified to have only a single interface method needing implementation.
<areahref="classcrashpad_1_1MachMessageServer_1_1Interface.html"title="A Mach RPC callback interface, called by Run(). "alt="crashpad::MachMessageServer::Interface"shape="rect"coords="0,0,249,24"/>
<trclass="memdesc:"><tdclass="mdescLeft"> </td><tdclass="mdescRight">An interface that the different request messages that are a part of the <code>exc</code> and <code>mach_exc</code> Mach subsystems can be dispatched to. <ahref="classcrashpad_1_1UniversalMachExcServer_1_1Interface.html#details">More...</a><br/></td></tr>
<trclass="memdesc:a05bf6aa6e6e692e998a8ba2d6b5a6c95"><tdclass="mdescLeft"> </td><tdclass="mdescRight">Constructs an object of this class. <ahref="#a05bf6aa6e6e692e998a8ba2d6b5a6c95">More...</a><br/></td></tr>
<divclass="textblock"><p>A server interface for the <code>exc</code> and <code>mach_exc</code> Mach subsystems, unified to handle exceptions delivered to either subsystem, and simplified to have only a single interface method needing implementation. </p>
<p>The <code><mach/exc.defs></code> and <code><mach/mach_exc.defs></code> interfaces are identical, except that the latter allows for 64-bit exception codes, and is requested by setting the MACH_EXCEPTION_CODES behavior bit associated with an exception port.</p>
<p><aclass="el"href="classcrashpad_1_1UniversalMachExcServer.html"title="A server interface for the exc and mach_exc Mach subsystems, unified to handle exceptions delivered t...">UniversalMachExcServer</a> operates by translating messages received in the <code>exc</code> subsystem to a variant that is compatible with the <code>mach_exc</code> subsystem. This involves changing the format of <em>code</em>, the exception code field, from <code>exception_data_type_t</code> to <code>mach_exception_data_type_t</code>. </p>
</div><h2class="groupheader">Constructor & Destructor Documentation</h2>
<p>This method is a stand-in for a MIG-generated Mach RPC server “demux” function such as <code>exc_server()</code> and <code>mach_exc_server()</code>. Implementations may call such a function directly. This method is expected to behave exactly as these functions behave.</p>
<dlclass="params"><dt>Parameters</dt><dd>
<tableclass="params">
<tr><tdclass="paramdir">[in]</td><tdclass="paramname">in</td><td>The request message, received as a Mach message. Note that this interface uses a <code>const</code> parameter for this purpose, whereas MIG-generated “demux” functions do not. </td></tr>
<tr><tdclass="paramdir">[out]</td><tdclass="paramname">out</td><td>The reply message. The caller allocates storage, and the callee is expected to populate the reply message appropriately. After returning, the caller will send this reply as a Mach message via the message’s reply port. </td></tr>
<tr><tdclass="paramdir">[out]</td><tdclass="paramname">destroy_complex_request</td><td><code>true</code> if a complex request message is to be destroyed even when handled successfully, <code>false</code> otherwise. The traditional behavior is <code>false</code>. In this case, the caller only destroys the request message in <em>in</em> when the reply message in <em>out</em> is not complex and when it indicates a return code other than <code>KERN_SUCCESS</code> or <code>MIG_NO_REPLY</code>. The assumption is that the rights or out-of-line data carried in a complex message may be retained by the server in this situation, and that it is the responsibility of the server to release these resources as needed. However, in many cases, these resources are not needed beyond the duration of a request-reply transaction, and in such cases, it is less error-prone to always have the caller, <aclass="el"href="classcrashpad_1_1MachMessageServer.html#ace981f2e495984f119aa074f7d33bff6"title="Runs a Mach message server to handle a Mach RPC request for MIG servers. ">MachMessageServer::Run()</a>, destroy complex request messages. To choose this behavior, this parameter should be set to <code>true</code>.</td></tr>
</table>
</dd>
</dl>
<dlclass="section return"><dt>Returns</dt><dd><code>true</code> on success and <code>false</code> on failure, although the caller ignores the return value. However, the return code to be included in the reply message should be set as <code>mig_reply_error_t::RetCode</code>. The non-<code>void</code> return value is used for increased compatibility with MIG-generated functions. </dd></dl>
<dlclass="section return"><dt>Returns</dt><dd>The maximum size, in bytes, of a reply message to be sent via the <em>out</em> parameter of <aclass="el"href="classcrashpad_1_1UniversalMachExcServer.html#a113ce518d5412e2cf352eb7f857fa9fb"title="Handles a Mach RPC request. ">MachMessageServerFunction()</a>. This value does not need to include the size of any trailer to be sent with the message. </dd></dl>
<dlclass="section return"><dt>Returns</dt><dd>The set of request message Mach message IDs that <aclass="el"href="classcrashpad_1_1UniversalMachExcServer.html#a113ce518d5412e2cf352eb7f857fa9fb"title="Handles a Mach RPC request. ">MachMessageServerFunction()</a> is able to handle. </dd></dl>
<dlclass="section return"><dt>Returns</dt><dd>The expected or maximum size, in bytes, of a request message to be received as the <em>in</em> parameter of <aclass="el"href="classcrashpad_1_1UniversalMachExcServer.html#a113ce518d5412e2cf352eb7f857fa9fb"title="Handles a Mach RPC request. ">MachMessageServerFunction()</a>. </dd></dl>
