Jinoh Kang (@iamahuman) commented about server/thread.c:
> + {
> + struct wait_completion_packet *packet;
> +
> + LIST_FOR_EACH_ENTRY( packet, &obj->wait_completion_packet_queue, struct wait_completion_packet, entry )
> + {
> + list_remove( &packet->entry );
> + release_object( packet->target );
> + packet->in_object_packet_queue = 0;
> + packet->target = NULL;
> +
> + add_completion( packet->completion, packet->ckey, packet->cvalue, packet->status,
> + packet->information, packet );
> + packet->in_completion_queue = 1;
> + }
> + }
> +
General advice: you should try not to leak implementation details of certain object (wait completion packet) into other types of objects.
For example, if this piece of code is still to be preserved, you should move this into a helper completion.c, declare as extern in object.h (or file.h), and call that.
That way, you don't have to define the entire `struct wait_completion_packet` in a shared header file. If this were factored into a helper, a simple forward declaration would have sufficed in the `file.h` side.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6911#note_91785
Use the irql assigned by IoAcquireCancelSpinLock, not the
(yet-to-be-assigned) irp->CancelIrql.
This is for readability. No semantic change is expected with unmodified
ntoskrnl.exe/hal.dll.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7129
Use the irql assigned by IoAcquireCancelSpinLock, not the
(yet-to-be-assigned) irp->CancelIrql.
This is for readability. Since IoReleaseCancelSpinLock() ignores the
IRQL argument anyway, no semantic change is expected with unmodified
ntoskrnl.exe/hal.dll.
--
v2: ntoskrnl.exe: Fix IRQL mismatch between cancel spin lock acquire and release.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7129
On Sat Dec 21 08:41:22 2024 +0000, Anton Baskanov wrote:
> The correct way to fix this is to implement a custom allocator like it
> is done in the native AMDirectDrawStream. This will allow changing the
> format on the fly without stopping the stream. But it of course requires
> much more work, including adding format change support to decoders.
Thanks for the feedback! I started reading about dynamic format changing and dynamic reconnecting from your comment, so now I have a better idea on how to continue with this. :-)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7057#note_91771
The new job is only triggered when a developer manually starts it.
Before run, it initially appears as a "skipped" job when the pipeline
starts.
--
v3: tools: Add manual-run job for new-style wow64.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7108