UnsafeQueueUserWorkItem和究竟是什么"不传播调用堆栈"意思？ [英] UnsafeQueueUserWorkItem and what exactly does "does not propagate the calling stack" mean?

问题描述

我读和学习 ThreadScheduler 和周围的任务物品和整个功能来 ThreadPool.UnsafeQueueUserWorkItem 用于的 MSDN的例子之一了解自己ThreadSchedulers。大约在UnsafeQueueUserWorkItem在MSDN 描述有一个很大的警告功能可能是一个安全漏洞，它的不传播调用堆栈的。

I am reading and learning about ThreadScheduler and articles around Tasks and came across the function ThreadPool.UnsafeQueueUserWorkItem used in one of the MSDN examples about own ThreadSchedulers. In the MSDN description about UnsafeQueueUserWorkItem there is a big warning that the function may be an security hole and that it "does not propagate the calling stack".

的唯一联系是 QueueUserWorkItem 其中 - 从名字 - 似乎是安全对口？但没有提到有关调用堆栈或者任何东西。

The only link is to QueueUserWorkItem which - from the name - seems to be the "safe counterpart"? but does not mention anything about calling stacks either.

这是什么恰恰意味着传播堆栈？在工作​​开始前复制呢？为什么另一个线程需要调用线程的堆栈呢？我会认为，他们开始用新鲜和空栈。毕竟，当线程函数返回，它不继续执行该功能调度任务，对吧？

What does that exactly mean to propagate a stack? Copy it over before the work starts? Why would another thread need the stack of the calling thread anyway? I would assume that they start with a fresh and empty stack. After all, when the thread function returns, it does not continue to execute the function scheduling the Task, right?

推荐答案

有CAS的实现细节，代码访问安全性。它可以检查一个线程是否有足够的权限来执行操作。它只有代码在受限制的安全环境中运行，不能完全信任或者在沙箱中运行的问题。

It is an implementation detail of CAS, Code Access Security. Which can check whether a thread has sufficient rights to perform an operation. It only matters if code runs in a restricted security environment, not running with full trust or in a sandbox.

这使得这项工作非常复杂，我只能大致的管道它的工作方式。该执行上下文类是关键，它决定了代码运行的安全上下文。事情变得困难时具有有限权限运行一个线程启动另一个线程。清楚，其他线程需要与相同种类的限制，原来的线程中运行。 CAS取决于能够执行堆栈走到发现限制。这是很难在另一个线程，它有它自己的堆栈。

The plumbing that makes this work is complicated and I can only approximate the way it works. The ExecutionContext class is key, it determines the security context in which code runs. Things get difficult when a thread that runs with restricted rights starts another thread. Clearly that other thread needs to run with the same kind of restrictions as the original thread. CAS depends on the being able to perform stack walks to discover restrictions. That's difficult on another thread, it has its own stack.

ExecutionContext.Capture（）方法执行这里了至关重要的作用。它使调用线程，包括制造一个堆栈遍历来创建发现的安全属性的压缩堆的上下文的拷贝。新线程然后与捕获的上下文中运行。

The ExecutionContext.Capture() method performs an essential role here. It makes a copy of the context of the calling thread, including making a stack walk to create a "compressed" stack of the security attributes discovered. The new thread then runs with that captured context.

ThreadPool.UnsafeQueueUserWorkItem（）跳过捕捉（）调用。线程池线程将使用默认的执行上下文中运行。

ThreadPool.UnsafeQueueUserWorkItem() skips the Capture() call. The threadpool thread will run with the default execution context.

这是一种优化，捕捉（）是不是一个便宜的方法。要紧的是依赖于TP线程得到的东西匆忙完成的一种方案。 Web服务器跳转到心灵。此外，使用该方法的那种代码，你看它在System.Net命名空间中，例如内部方法使用。

This is an optimization, Capture() is not a cheap method. It matters in the kind of program that depends on TP threads to get stuff done in a hurry. A web server jumps to mind. Also the kind of code that uses the method, you see it used in internal methods in the System.Net namespace for example.

显然，这是不安全的，它不与原始线程的限制CAS运行。

Clearly it is unsafe, it doesn't run with the CAS restrictions of the originating thread.

这篇关于UnsafeQueueUserWorkItem和究竟是什么"不传播调用堆栈"意思？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！