Consider a thread A running waiting_item_cancelable_callback() and a thread B running queue_cancel_item(),
which is the scenario from canceling a work item right after it gets submitted by RtwqPutWaitingWorkItem().
When the invoke_async_callback() call in queue_cancel_item() for item key with WAIT_ITEM_KEY_MASK in
thread B runs before the queue_release_pending_item() in waiting_item_cancelable_callback() in thread
A, the async callback is called the first time in queue_cancel_item() with RTWQ_E_OPERATION_CANCELLED,
then a second time in waiting_item_cancelable_callback(). We should check in queue_release_pending_item()
whether an item is already removed by queue_cancel_item() before calling async callbacks.
A different scenario could happen for scheduled_item_cancelable_callback() with the function ends
up calling its async callback even after it has been canceled by queue_cancel_item().
Consider a thread A running scheduled_item_cancelable_callback() and a thread B running queue_cancel_item(),
which is the scenario from canceling a work item right after it gets submitted by RtwqScheduleWorkItem().
When the CloseThreadpoolTimer() call in queue_cancel_item() in thread B runs before the queue_release_pending_item()
in scheduled_item_cancelable_callback() in thread A, scheduled_item_cancelable_callback() ends up
calling work_item_Release() and CloseThreadpoolTimer() is called again for the same timer object. So
the thread pool timer object end up getting released while the scheduled_item_cancelable_callback()
is running, triggering the '!object->num_running_callbacks' assertion in tp_object_release(). This
is actually a double free but the assertion happens before the second free could happen. The same
thing could happen for thread pool wait objects as well.
Fix mf and mfmediaengine tests sometimes trigger the '!object->num_running_callbacks' assertion.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55724
An extension of 3985b7c5. Opening the device for the Touch Bar on
older MacBooks also triggers a permission prompt, so for now it makes
sense to restrict the devices we open.
CDBurnerXP expects the ContextMenuHandlers key to exist, and apparently
enumerates it until it receives ERROR_NO_MORE_ITEMS. If it fails to open the
key, it will spin forever trying to call RegEnumKeyExW(NULL) and getting
ERROR_INVALID_HANDLE.
We could simply create an empty ContextMenuHandlers key here, but this will
allow the New menu to work in the builtin explorer view once shellex handlers
are implemented.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=29523
Much like we do in shader_spirv_find_graphics_program_variant_vk() for
shader_spirv_compile_shader(). When compiling an Aon9 shader,
"shader->byte_code" points to the DXBC container, while
"shader->function" points to the contained d3dbc shader.
This enables advanced color conversion in all cases, and thus allows
NV12 -> RGB32 conversion even when MF_SOURCE_READER_ENABLE_ADVANCED_VIDEO_PROCESSING
is not set. This should be harmless and makes the code simpler as we
can simply append a VideoProcessor transform in all cases.
The tests todos is tweaked to reflect cases where a single processor
is used, which outputs slightly different attributes to when it is
connected to an upstream decoder. Ultimately we could try to match
native here, but it shouldn't matter too much in the meantime.
