August 13, 2019 12:34 PM, "Chip Davis" cdavis@codeweavers.com wrote:
August 13, 2019 12:31 PM, "Alexandre Julliard" julliard@winehq.org wrote:
"Chip Davis" cdavis@codeweavers.com writes:
August 13, 2019 4:10 AM, "Alexandre Julliard" julliard@winehq.org wrote:
Chip Davis cdavis@codeweavers.com writes:
@@ -3062,14 +3062,14 @@ NTSTATUS WINAPI NtInitiatePowerAction( */ NTSTATUS WINAPI NtSetThreadExecutionState( EXECUTION_STATE new_state, EXECUTION_STATE *old_state ) {
- static EXECUTION_STATE current =
- ES_SYSTEM_REQUIRED | ES_DISPLAY_REQUIRED | ES_USER_PRESENT;
- *old_state = current;
- struct ntdll_thread_data *thread_data = ntdll_get_thread_data();
- *old_state = thread_data->exec_state;
WARN( "(0x%x, %p): stub, harmless.\n", new_state, old_state );
- if (!(current & ES_CONTINUOUS) || (new_state & ES_CONTINUOUS))
- current = new_state;
- if (new_state & ES_CONTINUOUS)
- thread_data->exec_state = new_state;
return STATUS_SUCCESS; }
This would most likely need to be stored in the server, it doesn't seem very useful to have in the local thread data.
My tests (patch 2) demonstrate that there are two distinct states here: the thread execution state, which is unique to each thread; and the system execution state, which is the union of all threads' execution states and active power request objects. Note in particular that setting thread A's execution state does not affect the return value of SetThreadExecutionState() for thread B.
Yes of course, but you won't be able to compute the system state if you store the thread state in the thread local data.
See patch 3 in the new series I just sent.
...And it just occurred to me that this won't work correctly when the thread terminates. Disregard.