On Wed Oct 1 07:42:32 2025 +0000, Alexandre Julliard wrote:
I don't think that this should constrain the implementation. We'll want to address it one way or another, but for now it would be OK to comment out the offending test.
I don't really see how splitting the fd sending over two different requests was so bad, or rather I think the problem comes from having two different requests for first / other threads init in the first place and that's unrelated to the thing we're doing here. It should / could be solved later (or before), but given how difficult it has been to iterate over wineserver design changes for ntsync, my current feeling is that I will unlikely be trying to myself.
About the proposed change, I don't think adding an extra request just to retrieve this ntsync specific fd on every thread init is better. I don't think having a request dedicated to retrieving that fd is nice in the first place, but I don't mind that much, and if we are going to do that then it's probably better to just delay the request until the fd is actually needed. I suppose it might end up failing if the client has too many open fds at that point, instead of failing thread creation, but maybe it's not a problem we should be caring for.
In any case, I can keep upstreaming the message queue changes, but I think that you should then take over the remaining changes (which would then be ~10 patches, after `server: Create event syncs for the message queues.` in https://gitlab.winehq.org/rbernon/wine/-/commits/wip/ntsync) after that because you seem to have specific ideas about how you would like things to be implemented here and the slow iterative process has been quite impractical and painful for everyone involved.