Re: [PATCH v2 0/6] MR8445: server: Create inproc sync events for message queues.

[Elizabeth Figura (＠zfigura)]

> The comment is added in a later change, when it really matters. For now the entries aren't cached.

But now it doesn't make sense why it's arranged like this. If you really want to defer things like that, you should get rid of the double-pointer return. Obviously I didn't do that because it would have required a lot of refactoring once I did start caching objects, although sometimes that kind of refactoring is preferable, but if you are similarly going to avoid it, you should explain why there's two parameters.
> Fwiw I kept a "cache" name for the stack variable but it should probably not even be named like that, it's not a cache. I don't think it matters much anyway, the code isn't so complicated.

I can see why you see it as not a cache, although I think it also kind of is: the canonical information lives in the server, the client side can be dropped and reacquired, and the code is intended to work even if we don't have memory to store that information.

But either way, we shouldn't name the single-pointer parameter just "cache". That's not its point compared to the double-pointer parameter; the point is to be a stack or fallback pointer to hold that information.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/8445#note_108294