chapter 8.8: canceled and suspended requests

驱动可以在任何时间停止处理I/O请求:
    1.发起request的线程或进程取消或离开
    2.PnP和Power事件,例如睡眠
    3.设备移除
驱动在收到请求时对请求取消(STATUS_CANCELLED)或完成error。
驱动应该为需要很长时间或不定时间的请求提供回调,比如非同步的input请求。


Request cancellation
WDF取消请求的行为取决于请求是否被传递给target driver
    1.若请求还没被queue或任在queue中,framework自动cancel或suspend
    2.若请求被传递,但只被传递给另一个queue,framework自动cancel或suspend
        驱动注册EvtIoCanceledOnQueue可以获得通知
    3.若请求被驱动获得,则framework不取消,但驱动可以标记请求是可取消的,并注册一个cancellation callback
标记请求可取消:
    UMDF:===
    KMDF:WdfRequestMarkCancelable/WdfRequestUnmarkCancelable
* 标记成可取消的请求无法被传递给另一个queue
驱动不允许让请求在uncancellable状态停留过长时间:长时间操作或不一定成功的操作。
KMDF:
    使用WdfRequestIsCancelled查看是否I/O manager或requester在取消请求。
下表总结了当request取消时的framework动作。

When cancellation occurs

The framework

Before the request has ever been delivered to the driver

Cancels the request. No driver code is required, and no notification is sent to the driver.

While the request is in a queue but after it has been delivered to the driver, which could occur if the driver receives an I/O request and then requeues it

Cancels the request. No driver code is required, and no notification is sent to the driver.

If a KMDF driver has registered an EvtIoCanceledOnQueue callback for the queue, invokes this callback, and then cancels the request; otherwise, cancels the request as described above. (KMDF only)

While the driver owns the request

If the driver has marked the request cancelable, calls the cancel callback that the driver registered for the request.

If the driver has not marked the request cancelable, does nothing.

The driver can call WdfRequestIsCanceled to find out whether the request has been canceled. (KMDF only)




Request Suspension
UMDF:
KMDF:为请求注册EvtIoStop,包含flag指示queue停止的原因和请求是否是能取消的
驱动可以:
    1.完成请求
    2.requeue请求
    3.若请求可以很快完成则忽略通知
    4.承认通知但仍保持请求
驱动应该为任何需要长时间完成的请求注册stop callback
### 回答1: 这个错误提示意思是等待容器时出现了上下文取消的情况。可能是由于某些原因导致容器无法启动或者启动过程中被中断了。建议检查容器的配置和环境,确保其正常运行。同时,也可以查看相关日志信息,以便更好地定位问题。 ### 回答2: 在Docker容器中,当容器启动时出现“error waiting for container: context canceled”消息时,这通常意味着 Docker 主机本身不能完成容器启动的要求。 该消息通常与Docker守护进程中断有关,可能是由于内存或磁盘空间不足或其他系统资源瓶颈导致的。如果Docker主机不足以提供所需的资源,它可能会自动取消执行容器的上下文,并停止容器的执行。 此外,该错误可能还涉及Docker主机与容器之间的其他通信问题,例如无法连接到容器网络或错误的环境变量设置。 要解决这种错误,可以尝试增加Docker主机的资源,以确保有足够的内存可用来支持容器。您还可以尝试检查主机上的磁盘空间,以确保该环境拥有必要的空间。另外可以指定正确的环境变量,检查Docker主机和容器之间的网络通信是否正确,以确保它们可以正确地互相通信。 当然,此错误可能是由其他许多因素引起的。如果这些快速调整仍然不能解决问题,建议尝试查看Docker日志以便找到更详细的错误信息,并进行相应的修复。 ### 回答3: “error waiting for container: context canceled”错误通常是由于Docker容器在等待特定资源时尝试完成任务而被中断或取消导致的。实际上,越来越多的Docker开发人员在处理容器中出现此错误时感到困惑,因为这个错误提示并不是很明显。 首先,我们需要了解Docker环境中的“context”概念。在Docker中,context是一个用于指定操作目标位置的路径或URL的集合。对于Docker客户端命令而言,它们会基于上下文执行操作。Docker客户端可以与Docker引擎通信,以便在特定环境中构建和运行容器。 当Docker容器无法获得所需资源并等待时,如果在太长时间内没有获得响应,Docker守护进程就会因为过期而取消这个容器的上下文(context)。此时,容器就会出现错误,并提示“error waiting for container: context canceled”错误信息。 因此,解决这个错误问题的关键是确保Docker容器可以及时获得所需资源,并避免在过长的时间内等待容器资源。可以尝试以下方法解决这个问题: 1. 调整Docker容器的资源限制,避免资源瓶颈导致无法获取所需资源,并能够加速资源请求。 2. 防止其他程序或脚本占用Docker容器所需的资源,从而导致Docker容器无法获取所需资源。 3. 确保使用的Docker镜像是最新的,并且能够与当前的Docker环境完全兼容,以避免版本冲突的问题。 总的来说,“error waiting for container: context canceled”错误是一个比较普遍的Docker容器问题。需要针对具体的情况进行调整,例如优化容器设置或更改Docker相关配置等操作,来避免这个错误的发生。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值