Startup and lock counts in native Windows are separate, and the lock count does not decrease when an async result is freed if the platform has been started.
--
v9: rtworkq: Do not cancel pending callbacks when closing a thread pool.
rtworkq/tests: Test queue shutdown with pending items.
rtworkq/tests: Test scheduled items.
mfplat/tests: Check for async result release after canceling work and shutting down.
mfplat/tests: Release callback2 in test_event_queue().
mfplat: Free the inner cookie passed to resolver_create_cancel_object().
rtworkq: Introduce an async result object cache.
rtworkq: Introduce a platform startup count.
rtworkq/tests: Test work queue.
mfplat/tests: Test platform startup and lock counts.
mfplat/tests: Test mixing of MF platform functions with their Rtwq equivalents.
mfplat/tests: Introduce a helper to check the platform lock count.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7174
This mitigates a side effect of the global current_time and monotonic_time being updated on every server call's timeout, where the end time of any unrelated server call is moved into the future (depending on the frequency of server calls).
By using a more granular timeout, the overall frequency of server calls doesn't have as great of an effect on each individual timeout, as we don't have to wait for an entire millisecond (which was due to the ceiling operation in get_next_timeout).
This [issue](https://bugs.winehq.org/show_bug.cgi?id=57849) gives a few examples of this causing significant degradation in the behavior of some games, which use alertable (server) waits for their FPS limiter.
--
v5: server: Use epoll_pwait2 if supported.
server: Convert to and use a timespec directly for timeouts if supported.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7392
This mitigates a side effect of the global current_time and monotonic_time being updated on every server call's timeout, where the end time of any unrelated server call is moved into the future (depending on the frequency of server calls).
By using a more granular timeout, the overall frequency of server calls doesn't have as great of an effect on each individual timeout, as we don't have to wait for an entire millisecond (which was due to the ceiling operation in get_next_timeout).
This [issue](https://bugs.winehq.org/show_bug.cgi?id=57849) gives a few examples of this causing significant degradation in the behavior of some games, which use alertable (server) waits for their FPS limiter.
--
v4: server: Use epoll_pwait2 if supported.
server: Convert to and use a timespec directly for timeouts if supported.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7392
This mitigates a side effect of the global current_time and monotonic_time being updated on every server call's timeout, where the end time of any unrelated server call is moved into the future (depending on the frequency of server calls).
By using a more granular timeout, the overall frequency of server calls doesn't have as great of an effect on each individual timeout, as we don't have to wait for an entire millisecond (which was due to the ceiling operation in get_next_timeout).
This [issue](https://bugs.winehq.org/show_bug.cgi?id=57849) gives a few examples of this causing significant degradation in the behavior of some games, which use alertable (server) waits for their FPS limiter.
--
v3: server: Use epoll_pwait2 if supported.
server: Convert to and use a timespec directly for timeouts if supported.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7392