[PATCH 1/2] ntdll: Improve NtSetThreadExecutionState() stub.

[Chip Davis]

August 13, 2019 12:31 PM, "Alexandre Julliard" <julliard at winehq.org> wrote:

> "Chip Davis" <cdavis at codeweavers.com> writes:
> 
>> August 13, 2019 4:10 AM, "Alexandre Julliard" <julliard at winehq.org> wrote:
>> 
>>> Chip Davis <cdavis at 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.

Chip