Doron
Thu Dec 13 12:41:03 PST 2007
queues do not have their own threads. the nt driver model, umd or kmdf or
WDM is that you do not block in the queue / dispatch routine. rather you
put it in the queue and the process it sometime later asynchronously w/out
blocking. for instance in your timer case, you can create a waitable timer
and then complete the request in the TimerAPC routine used when you set the
timer
d
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Andre" <Andre@discussions.microsoft.com> wrote in message
news:8A35B4F9-62C3-4F79-B3A6-3C64FF58B780@microsoft.com...
> Doron,
>
> Thanks for your response. I see that this would solve the blocking issue.
> However, it does not really answer the question. The WdfIoQueues would be
> even more usefull if they could be configured to decouple the processing
> from
> the request.
>
> E.g. if I have a transmit operation with timeout parameter, then I would
> forward a respective request to such a transmit request queue. In the
> context
> of the OnWrite callback for the transmit request queue I would start the
> transmit operation and wait for it to complete or to timeout. This means
> the
> OnWrite blocks processing for the transmit request queue, but it should
> not
> block the other queues through which the original request was routed.
>
> Currently I have to setup another thread which handles the requests in its
> context asynchronously.
>
> "Doron Holan [MSFT]" wrote:
>
>> do not block in the queue you are forwarding to. in the final fwd'ed
>> queue,
>> return and complete the reques later when conditions are correct to
>> complete
>> it
>>
>> d
>>
>> --
>> Please do not send e-mail directly to this alias. this alias is for
>> newsgroup purposes only.
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>> "Andre" <Andre@discussions.microsoft.com> wrote in message
>> news:3C7DD180-CA4A-4FE2-8834-6CACF16B03F5@microsoft.com...
>> > Hello,
>> >
>> > I am using different IoQueues for read, write, and IoControl requests
>> > in
>> > an
>> > UMDF driver. A request is first handled by an DefaultIoHandler and then
>> > forwarded to its respective queue using the method
>> > IWDFIoRequest::ForwardToIoQueue. I would expect, that this method
>> > returns
>> > immediately after it requeued the request, but instead the request is
>> > handled
>> > in the context of ForwardToIoQueue. Therefore, the call blocks until
>> > the
>> > request has been completed. This happens even when forwarding over
>> > multiple
>> > queues. Note, that these queues are configure with
>> > WdfIoQueueDispatchParallel or WdfIoQueueDispatchSequential.
>> >
>> > I suppose I could use manual queues from which I can retrieve requests
>> > in
>> > a
>> > thread separately created by my driver, to decouple the actual
>> > processing
>> > from the request. Is this the recommended way?
>> >
>> > What is the point of forwarding, if it does not return immediately?
>> >
>> > Thanks in advance for any comments or sugestions!
>> >
>> > Regards,
>> > Andre
>> >
>> >
>>
>>