dr_create_client_thread

Function dr_create_client_thread 

Source
pub unsafe extern "C" fn dr_create_client_thread(
    func: Option<unsafe extern "C" fn(param: *mut c_void)>,
    arg: *mut c_void,
) -> bool_
Expand description

Creates a new thread that is marked as a non-application thread (i.e., DR will let it run natively and not execute its code from the code cache). The thread will terminate automatically simply by returning from \p func; if running when the application terminates its last thread, the client thread will also terminate when DR shuts the process down.

Init and exit events will not be raised for this thread (instead simply place init and exit code in \p func).

The new client thread has a drcontext that can be used for thread-private heap allocations. It has a stack of the same size as the DR stack used by application threads.

On Linux, this thread is guaranteed to have its own private itimer if dr_set_itimer() is called from it. However this does mean it will have its own process id.

A client thread should refrain from spending most of its time in calls to other libraries or making blocking or long-running system calls as such actions may incur performance or correctness problems with DR’s synchronization engine, which needs to be able to suspend client threads at safe points and cannot determine whether the aforementioned actions are safe for suspension. Calling dr_sleep(), dr_thread_yield(), dr_messagebox(), or using DR’s locks are safe. If a client thread spends a lot of time holding locks, consider marking it as un-suspendable by calling dr_client_thread_set_suspendable() for better performance.

Client threads, whether suspendable or not, must never execute from the code cache as the underlying fragments might be removed by another thread.

Client threads are suspended while DR is not executing the application. This includes initialization time: the client thread’s \p func code will not execute until DR starts executing the application.

\note Thread creation via this routine is not yet fully transparent: on Windows, the thread will show up in the list of application threads if the operating system is queried about threads. The thread will not trigger a DLL_THREAD_ATTACH message. On Linux, the thread will not receive signals meant for the application, and is guaranteed to have a private itimer.