IWDFIoRequest::ForwardToIoQueue does not return immediately

Discussion in 'Windows Vista Drivers' started by Andre, Dec 12, 2007.

  1. Andre

    Andre Guest

    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
     
    Andre, Dec 12, 2007
    #1
    1. Advertisements

  2. 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
     
    Doron Holan [MSFT], Dec 13, 2007
    #2
    1. Advertisements

  3. Andre

    Andre Guest

    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.
     
    Andre, Dec 13, 2007
    #3
  4. 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.
     
    Doron Holan [MSFT], Dec 13, 2007
    #4
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.