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

[Chip Davis]

August 13, 2019 12:34 PM, "Chip Davis" <cdavis at codeweavers.com> wrote:

> 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.

...And it just occurred to me that this won't work correctly when the thread terminates. Disregard.