[PATCH 0/1] MR3531: mfplat: Use the io queue for bytestream requests.

[Rémi Bernon (＠rbernon)]

Avoid blocking the default callback queue with file I/O.

[PATCH 1/1] mfplat: Use the io queue for bytestream requests.

[Rémi Bernon]

From: Rémi Bernon

---
 dlls/mfplat/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dlls/mfplat/main.c b/dlls/mfplat/main.c
index 8aaf9f93cdc..96ec23fba9b 100644
--- a/dlls/mfplat/main.c
+++ b/dlls/mfplat/main.c
@@ -3811,7 +3811,7 @@ static HRESULT bytestream_create_io_request(struct bytestream *stream, enum asyn
             &stream->write_callback, NULL, &request)))
         goto failed;

-    RtwqPutWorkItem(MFASYNC_CALLBACK_QUEUE_STANDARD, 0, request);
+    RtwqPutWorkItem(MFASYNC_CALLBACK_QUEUE_IO, 0, request);
     IRtwqAsyncResult_Release(request);

failed:

[Nikolay Sivov (＠nsivov)]

Is there an evidence of this happening? Maybe we should be using BeginRead/EndRead? I remember testing that with file byte stream, and it was using something in overlapped data in MFASYNCRESULT structure.

[Rémi Bernon (＠rbernon)]

On Tue Aug  8 13:29:19 2023 +0000, Nikolay Sivov wrote:
> Is there an evidence of this happening? Maybe we should be using
> BeginRead/EndRead? I remember testing that with file byte stream, and it
> was using something in overlapped data in MFASYNCRESULT structure.

Well this **is** used to implement our async BeginRead/BeginWrite, which I'd like to use without blocking the callback queue. We use an async MF operation which calls the synchronous Read, and which is queued on the callback queue (currently) and I'd like to move it to the I/O queue.

I can probably add tests, but I suspect that the asynchronous operations might be implemented differently depending on the byte stream implementation, and maybe the file based streams use async file I/O directly?