https://bugs.winehq.org/show_bug.cgi?id=41107
Gabriel Ivăncescu gabrielopcode@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gabrielopcode@gmail.com
--- Comment #19 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Hi Sebastian,
I want to fix this bug properly, without having this performance problem due to polling.
Do you have some testcases or anything? I mean, I totally understand the patch is proper behavior, and I'm not doubting that. But I need some testcases, or at least a bug report, or something to reproduce, so I can test it when I attempt my fix, i.e. so I don't end up making the patch not do its intended purpose.
Honestly, a test case would also be good so I can try to upstream it to wine-devel, but a bug report should be ok too :-) I mean the patch does fix at least an app, right?
Now onto the fix: I have two ideas. The first one is to use 'waitpid' with WNOHANG in thread_signaled *if* we are polling (so it's non-NULL), in which case we don't have to wait for the result of the polling to give a proper answer. Polling would still be used (but with the original interval if you want, to reduce the overhead) to clean up after the thread as usual. We can't rely on thread_signaled to cleanup by itself (without polling) since that function may not be called early enough and then we may end up with a re-used pid/tid, which is nasty.
The second idea is to spawn a new thread instead of polling. This thread would 'waitpid' on the thread (hanging) and when done, write to a field in the thread's structure indicating it finished, and then cleanup as usual. This is more "elegant" than polling, but spawning a new thread to terminate a thread makes me think it's quite overkill.
Obviously, these are just theories for now since I can only test Total Commander's performance, as I don't know what else this current patch fixes. That's why a testcase or bug report would be very helpful.