--
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
> 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
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
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
> 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