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
This fixes https://bugs.winehq.org/show_bug.cgi?id=52094.
For reference, here's how current_modref is being passed around (before this patch):
```mermaid
graph TB
fii["fixup_imports_ilonly<br><em style='color:#ff0'>(directly sets current_modref)</em>"]
fi["fixup_imports<br><em style='color:#ff0'>(directly sets current_modref)</em>"]
pa["process_attach<br><em style='color:#ff0'>(directly sets current_modref)</em>"]
ld[load_dll]
id["import_dll<br><em style='color:#0f0'>(directly uses current_modref)</em>"]
bin["build_import_name<br><em style='color:#0f0'>(directly uses current_modref)</em>"]
foe["find_ordinal_export<br><em style='color:#0f0'>(uses current_modref for relay)</em>"]
ffe["find_forwarded_export<br><em style='color:#0f0'>(directly uses current_modref)</em>"]
fne[find_named_export]
MI[MODULE_InitDLL]
fii --> ld
fi --> id
pa --> MI -.-> DllMain
id --> bin
id --> ld
id --> foe
id --> fne --> foe --> ffe --> foe
ffe --> fne
ffe --> bin
style DllMain color:red;
```
--
v15: ntdll: Remove superflous NULL check for importer.
ntdll: Properly track refcount on dynamic imports of export forwarders.
ntdll: Explicitly ignore dynamic (GetProcAddress) importers as relay/snoop user module.
ntdll: Eagerly call process_attach() on dynamic imports of export forwarders.
ntdll: Properly track refcount on static imports of export forwarders.
ntdll: Register module dependency for export forwarders regardless of whether the dependency is already loaded.
ntdll: Don't re-add a module dependency if it already exists.
ntdll: Sink module dependency registration towards the end of the
https://gitlab.winehq.org/wine/wine/-/merge_requests/7
On Thu Feb 20 21:41:59 2025 +0000, Paul Gofman wrote:
> On Windows sleep / timer resolution is 16ms by default however. That can
> be changed systemwide with NtSetTimerResolution() /
> winmm.timeBeginPeriod and AFAIK (didn't test that myself) 0.5ms is the
> best supported resolution (only available through NtSetTimerResolution).
> So it is interesting what the game does exactly, which sort of delays or
> waits affect the performance and how that works on Windows.
> Just making sleep precision as good as possible might instead negatively
> affact the performance in some other games.
Well, for one, I'd like to see an example of a real game that doesn't call timeBeginPeriod(1), but that's besides the point. We already simulate a 1ms timer period by having the tick count increase every millisecond, and this is absolutely not intended to change that.
What this is addressing is unrelated server calls from other threads pushing the **global** `current_time` and `monotonic_time` (updated each timeout) forward. That causes the timeouts for alertable `SleepEx` (used in those games' frame limiters) to expire for up to 1ms from that last update, as it's ceil'd to the next millisecond to avoid spinning with a 0 timeout. This causes, on average, an additional 0.5ms waited, depending on where we land on the tick boundary.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7392#note_95431
On Windows sleep / timer resolution is 16ms by default however. That can be changed systemwide with NtSetTimerResolution() / winmm.timeBeginPeriod and AFAIK (didn't test that myself) 0.5ms is the best supported resolution (only available through NtSetTimerResolution). So it is interesting what the game does exactly, which sort of delays or waits affect the performance and how that works on Windows.
Just making sleep precision as good as possible might instead negatively affact the performance in some other games.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7392#note_95428
Since commit 7620f21ff98 (makefiles: Generate the wow64 symlinks from
makedep., 2025-02-18), makedep generates a symlink target for
"<wine64_dir>/loader-wow64". This causes <wine64-dir> to be added as an
"ignore path," ultimately leading to create_file_directories() and then
create_dir().
create_dir() only expects relative paths. If it's passed an absolute
path, it will recognize the "/" prefix as an empty path component
followed by slash, and will attempt to mkdir(""), which fails.
Fix this by skipping initial slashes in create_dir().
Fixes: 7620f21ff98a85249b0b110bcba9953b32763f28
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7371
Trivial, small set of cleanups patches to start with, non-controversial and NOP functionally speaking.
These are to help get the review process going in making ways towards the bar being lowered for contributing to the oleaut32 implementation.
Signed-off-by: Edward O'Callaghan <edward(a)antitrust.cc>
--
v2: dlls/oleaut32: Fix ITypeLib2_Constructor_SLTG() regression
dlls/oleaut32: Invert if-stmt in ITypeLib2_fnRelease()
dlls/oleaut32: Invert if stmt for clarity
dlls/oleaut32: Consistently use TLB_REF_NOT_FOUND
https://gitlab.winehq.org/wine/wine/-/merge_requests/7375
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.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7392