October 2025 - Wine-gitlab - list.winehq.org

Re: [PATCH v2 0/2] MR9225: opengl32: Implement front buffer rendering emulation. - approved
by Alexandre Julliard (＠julliard) 20 Oct '25

20 Oct '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9225

1 0

Re: [PATCH v3 0/3] MR9224: win32u: Restore queue masks after processing driver events. - approved
by Alexandre Julliard (＠julliard) 20 Oct '25

20 Oct '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9224

1 0

Re: [PATCH v2 0/2] MR9213: d2d1/tests: Add some tests for resulting format of the WIC target. - approved
by Alexandre Julliard (＠julliard) 20 Oct '25

20 Oct '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9213

1 0

Re: [PATCH v2 0/4] MR9216: oleaut32/tests: Enable more tests for VarAdd(). - approved
by Alexandre Julliard (＠julliard) 20 Oct '25

20 Oct '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9216

1 0

[PATCH v3 0/7] MR9136: mshtml: Use a common object implementation for collection enumerators.
by Gabriel Ivăncescu 20 Oct '25

20 Oct '25

-- v3: mshtml: Use the common object implementation for HTMLAttributeCollection mshtml: Use the common object implementation for HTMLStyleSheetsCollection mshtml: Use the common object implementation for HTMLRectCollection mshtml: Use the common object implementation for HTMLSelectElement enumerator. mshtml: Use the common object implementation for HTMLFormElement enumerator. mshtml: Use the common object implementation for HTMLDOMChildrenCollection mshtml: Use a common object implementation for HTMLElementCollection https://gitlab.winehq.org/wine/wine/-/merge_requests/9136

2 10

Re: [PATCH v2 0/1] MR9234: ntdll: Call cache_inproc_sync() inside the lock.
by Elizabeth Figura (＠zfigura) 20 Oct '25

20 Oct '25

> Hmm... If the cache update is outside of the lock, more than one thread might have retrieved the sync and try to update the cache concurrently. > > I think in the current state this will break as multiple thread may pass the `if (InterlockedCompareExchange( &cache->refcount, 0, 0 ))` check successfully. Oh duh, I can't read. I'll adjust this patch to get rid of the atomic cmpxchg mapping cache memory as we indeed don't need it anymore with the lock. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9234#note_119104

1 0

Re: [PATCH v2 0/1] MR9234: ntdll: Call cache_inproc_sync() inside the lock.
by Rémi Bernon 20 Oct '25

20 Oct '25

On Mon Oct 20 21:11:35 2025 +0000, Rémi Bernon wrote: > Hmm... If the cache update is outside of the lock, more than one thread > might have retrieved the sync and try to update the cache concurrently. > I think in the current state this will break as multiple thread may pass > the `if (InterlockedCompareExchange( &cache->refcount, 0, 0 ))` check successfully. With a separate lock, we still have to only allow one of the thread to cache its sync, and let the others on the stack. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9234#note_119102

1 0

Re: [PATCH v2 0/1] MR9234: ntdll: Call cache_inproc_sync() inside the lock.
by Rémi Bernon 20 Oct '25

20 Oct '25

On Mon Oct 20 21:05:58 2025 +0000, Elizabeth Figura wrote: > > Nvm, I guess the entire sync retrieval and caching needs to be atomic. > Does it? I'm not sure I see how; I think you're right that the mmap > doesn't need to be in the lock. I don't know that it's really important, > given how rare it'll be in practice, but theoretically it could be > outside the lock. Hmm... If the cache update is outside of the lock, more than one thread might have retrieved the sync and try to update the cache concurrently. I think in the current state this will break as multiple thread may pass the `if (InterlockedCompareExchange( &cache->refcount, 0, 0 ))` check successfully. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9234#note_119101

1 0

Re: [PATCH v2 0/1] MR9234: ntdll: Call cache_inproc_sync() inside the lock.
by Elizabeth Figura (＠zfigura) 20 Oct '25

20 Oct '25

> Nvm, I guess the entire sync retrieval and caching needs to be atomic. Does it? I'm not sure I see how; I think you're right that the mmap doesn't need to be in the lock. I don't know that it's really important, given how rare it'll be in practice, but theoretically it could be outside the lock. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9234#note_119099

1 0

Re: [PATCH v2 0/1] MR9234: ntdll: Call cache_inproc_sync() inside the lock.
by Rémi Bernon 20 Oct '25

20 Oct '25

On Mon Oct 20 20:56:40 2025 +0000, Rémi Bernon wrote: > Sorry to have missed that. > Fwiw I think the lock (and probably a different one, there's no need to > lock the fd cache) should be taken again within `cache_inproc_sync` but > only for the things where it's actually necessary. > It does rather costly calls, like `mmap` and there's things like > `InterlockedCompareExchangePointer` in it which are rather pointless otherwise. Nvm, I guess the entire sync retrieval and caching needs to be atomic. Anyway, still I think the compare exchange looks confusing if it always happens inside a lock. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9234#note_119098

1 0