https://bugs.winehq.org/show_bug.cgi?id=56260
--- Comment #11 from Fabian Maurer dark.shadow4@web.de ---
The only function that calls WOWTHUNK_CallWithRegs with interrupt=FALSE is NE_StartTask, and the only function that calls NE_StartTask is task_start, which already locks Win16Mutex for the duration of the call. It didn't seem necessary to lock the mutex again, which would simply increment the lock count. Do you see anything that might depend on that side effect?
Not really, but I'm missing the bigger picture. Win16 lock has the weird behavior that can be gotten multiple times recursively, but I don't know how important the actual count is. Probably not too important.
I thought about that, but SetPriority16 needs to remove a running task from the list and then add it back to the end of the list, and Task_SuspendAll needs all potentially running tasks to be in the list at all times. So, SetPriority16 can't unlock task_list_cs in between TASK_UnlinkTask and TASK_LinkTask. Similarly, TASK_CreateMainTask needs to hold the lock in between when it starts the main task and when it adds it to the list. In task_start we could set pTask->teb before locking task_list_cs, but there doesn't seem to be much to gain one way or the other.
Ah, I see.