Server Interface - Handles the occurrence of an exception within a thread.
kern_return_t catch_exception_raise
(mach_port_t exception_port,
mach_port_t thread,
mach_port_t task,
exception_type_t exception,
exception_data_t code,
mach_msg_type_number_t code_count);
catch_exception_raise_state expanded form:
kern_return_t catch_exception_raise_state
(mach_port_t exception_port,
exception_type_t exception,
exception_data_t code,
mach_msg_type_number_t code_count,
int * flavor,
thread_state_t in_state,
mach_msg_type_number_t in_state_count,
thread_state_t out_state,
mach_msg_type_number_t * out_state_count);
catch_exception_raise_state_identity expanded form:
kern_return_t catch_exception_raise_state_identity
(mach_port_t exception_port,
mach_port_t thread,
mach_port_t task,
exception_type_t exception,
exception_data_t code,
mach_msg_type_number_t code_count,
int * flavor,
thread_state_t in_state,
mach_msg_type_number_t in_state_count,
thread_state_t out_state,
mach_msg_type_number_t * out_state_count);
A catch_exception_raise function is called by exc_server as the result of a kernel message indicating that an exception occurred within a thread. The exception_port parameter specifies the port named via a previous call to thread_set_exception_ports or task_set_exception_ports as the port that responds when the thread takes an exception.
The alternate message forms (the format being selected when the exception port was set) allow for selected thread state to be included.
When an exception occurs in a thread, the thread sends an exception message to its exception port, blocking in the kernel waiting for the receipt of a reply. It is assumed that some task is listening (most likely with mach_msg_server) to this port, using the exc_server function to decode the messages and then call the linked in catch_exception_raise. It is the job of catch_exception_raise to handle the exception and decide the course of action for thread.
If the thread should continue from the point of exception, catch_exception_raise would return KERN_SUCCESS. This causes a reply message to be sent to the kernel, which will allow the thread to continue from the point of the exception. If some other action should be taken by thread, the following actions should be performed by catch_exception_raise:
A thread can have two exception ports active for it: its thread type specific exception port and the task type specific exception port. The kernel will try sending an exception message to both ports looking for a reply message with a return value of KERN_SUCCESS. The kernel tries the thread specific port first, then the task specific port. If the return value from the first exception message the kernel sends has a return value of KERN_SUCCESS, the thread continues (with a possibly modified state). If the return value is not KERN_SUCCESS, the kernel tries the second port. If that return value is KERN_SUCCESS, the thread continues; otherwise, the thread is terminated.
To get the effect of a non-success return value, the server interface should return MIG_DESTROY_REQUEST. This causes exc_server and mach_msg_server to destroy the kernel's request (as opposed to sending a reply with a KERN_SUCCESS value).
A return value of KERN_SUCCESS indicates that the thread is to continue from the point of exception. A return value of MIG_NO_REPLY indicates that the exception was handled directly and the thread was restarted or terminated by the exception handler. A return value of MIG_DESTROY_REQUEST causes the kernel to try another exception handler (or terminate the thread). Any other value will cause mach_msg_server to remove the task and thread port references.
Functions: exc_server, thread_abort, task_get_exception_ports, thread_get_exception_ports, thread_get_state, thread_resume, task_set_exception_ports, thread_set_exception_ports, task_swap_exception_ports, thread_swap_exception_ports, thread_set_state, thread_suspend, thread_terminate. \ No newline at end of file +
+Server Interface - Handles the occurrence of an exception within a thread. + +
+kern_return_t catch_exception_raise + (mach_port_t exception_port, + mach_port_t thread, + mach_port_t task, + exception_type_t exception, + exception_data_t code, + mach_msg_type_number_t code_count); ++
+catch_exception_raise_state +expanded form: +
+kern_return_t catch_exception_raise_state + (mach_port_t exception_port, + exception_type_t exception, + exception_data_t code, + mach_msg_type_number_t code_count, + int * flavor, + thread_state_t in_state, + mach_msg_type_number_t in_state_count, + thread_state_t out_state, + mach_msg_type_number_t * out_state_count); ++
+catch_exception_raise_state_identity +expanded form: +
+kern_return_t catch_exception_raise_state_identity + (mach_port_t exception_port, + mach_port_t thread, + mach_port_t task, + exception_type_t exception, + exception_data_t code, + mach_msg_type_number_t code_count, + int * flavor, + thread_state_t in_state, + mach_msg_type_number_t in_state_count, + thread_state_t out_state, + mach_msg_type_number_t * out_state_count); ++
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+A catch_exception_raise function is called by +exc_server as the result of a +kernel message indicating that an exception occurred within a thread. +The exception_port parameter specifies the port named via +a previous call to thread_set_exception_ports or +task_set_exception_ports +as the port that responds when the thread takes an +exception. +
+The alternate message forms (the format being selected when the exception port +was set) allow for selected thread state to be included. + +
+When an exception occurs in a thread, the thread sends an exception message to +its exception port, blocking in the kernel waiting for the receipt of a reply. It is +assumed that some task is listening +(most likely with mach_msg_server) to this +port, using the exc_server function +to decode the messages and then call the +linked in catch_exception_raise. +It is the job of catch_exception_raise to handle +the exception and decide the course of action for thread. +
+If the thread should continue from the point of exception, +catch_exception_raise would return KERN_SUCCESS. This causes a reply +message to be sent to the kernel, which will allow the thread to continue from +the point of the exception. +If some other action should be taken by thread, the following actions should be +performed by catch_exception_raise: +
+
+
+
+A thread can have two exception ports active for it: its thread type specific exception +port and the task type specific exception port. The kernel will try sending +an exception message to both ports looking for a reply message with a +return value of KERN_SUCCESS. The kernel tries the thread specific port first, +then the task specific port. If the return value from the first exception message +the kernel sends has a return value of KERN_SUCCESS, the thread continues +(with a possibly modified state). If the return value is not KERN_SUCCESS, +the kernel tries the second port. If that return value is KERN_SUCCESS, the +thread continues; otherwise, the thread is terminated. +
+To get the effect of a non-success return value, the server interface should return +MIG_DESTROY_REQUEST. This causes exc_server and mach_msg_server +to destroy the kernel's request (as opposed to sending a reply with a +KERN_SUCCESS value). + +
+A return value of KERN_SUCCESS indicates that the thread is to continue +from the point of exception. A return value of MIG_NO_REPLY indicates that +the exception was handled directly and the thread was restarted or terminated by +the exception handler. A return value of MIG_DESTROY_REQUEST causes +the kernel to try another exception handler (or terminate the thread). Any other +value will cause +mach_msg_server to remove the task and thread port references. + +
+Functions: +exc_server, +thread_abort, +task_get_exception_ports, +thread_get_exception_ports, +thread_get_state, +thread_resume, +task_set_exception_ports, +thread_set_exception_ports, +task_swap_exception_ports, +thread_swap_exception_ports, +thread_set_state, +thread_suspend, +thread_terminate.