Thread objects are the active entities in Fluke. They represent independent flows of control and contain CPU register state among other things. A thread requires an address space context (task) and CPU resources (a scheduler) to run.
Many of the defined thread operations cannot be performed on the invoking (``current'') thread (e.g., fluke_thread_destroy, fluke_thread_get_state) while others can only be performed on the calling thread (e.g., fluke_thread_enable_exceptions, fluke_thread_disable_exceptions). Consult the appropriate API section for details.
All API calls which operate on the calling thread take a ``current thread'' parameter. The rationale is that finding the current thread may be somewhat expensive, even on Fluke implementations that do it entirely in user mode. Since threads that perform these operations are likely to do so often (e.g., calling the operations in pairs to disable and then reenable exceptions) or have a pointer to the current thread already available (e.g., in an exception handler), it is likely to be more efficient if the thread calls fluke_thread_self once and uses that returned pointer for all other calls. A Fluke implementation is free to ignore the parameter if it desires.
Collecting the state of a thread with fluke_thread_get_state stops the thread if it is running and prevents the thread from running again until fluke_thread_set_state is called with the FLUKE_THREAD_STOPPED bit cleared. There is no guarantee on how quickly a running target thread will be stopped, only that it will be stopped when the fluke_thread_get_state call returns.