> This works but it looks fragile. I haven't actually checked, but is there any other way that the same async can be terminated twice?
Yes. Consider the following scenario on `async`:
1. I/O timeout is configured for `async` via an `async_set_timeout()` call.
1. `async` enters alerted state.
2. An application calls `NtCancelIoFileEx` with `async`'s user IOSB.
3. `async_terminate( async, STATUS_CANCELLED )` is called.
4. The timeout expires.
5. `async_terminate( async, async->timeout_status );` is called. (`async->timeout_status` is usually `STATUS_TIMEOUT`.)
Furthermore, I/O cancellation and timeout can race with other async termination requests.
> If so, is it correct to buffer the second termination (and not, say, buffer a third?)
I don't think so. `async_terminate()` is currently no-op if the async has already been terminated with a status other than `STATUS_ALERTED`, and the patch maintains this invariant.
> If not, should we make this explicitly a boolean flag ('canceled' I guess?)
It is possible to introducing a new boolean flag, but the flag cannot replace `terminate_status`. `terminate_status` can be any arbitrary value passed as the third parameter of `async_set_timeout`.
Alternatively, we can rename `terminate_status` to `cancel_status` or `cancellation_status` (may be a bit misleading: is a timeout a cancellation?)
> Or at least add some asserts to communicate exactly when this is supposed to happen?
Right now I don't see any additional invariants that the new code paths would expect. `terminate_status` simply means the first status that the async was terminated with, other than `STATUS_ALERTED`. Termination can happen regardless of whether the async is in alerted state, but `terminate_status` would be used in `async_set_result` only if `async->alerted`. Can you suggest what the assertions would be?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/499#note_30342
MSVC doesn't support "name...".
---
msvc also supports __VA_ARGS__ only if /Zc:preprocessor is set to make
its preprocessor "standards conformant" instead of doing whatever msvc
used to do since aeons.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2666
Stop changing their attributes in place. This is complex, somewhat brittle, and
currently broken for the Vulkan backend.
Restrict wined3d_texture_update_desc() to changing user memory and pitch.
--
v3:
https://gitlab.winehq.org/wine/wine/-/merge_requests/2535
On Mon Apr 17 05:52:45 2023 +0000, Biswapriyo Nath wrote:
> Yes, all the IDL files are updated wrt. wine.
It's likely the generated header is the cause of the issue. Specifically, it should define the enums prior to their use. So it looks like an issue with WIDL. I'm not sure if this is something that Wine would support, but you can try asking in wine-devel, the IRC chat, or just open a wine-bug for it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2595#note_30316