我正在阅读和学习关于ThreadScheduler的文章和关于任务的文章,并偶然发现了ThreadPool.UnsafeQueueUserWorkItem函数,该函数在MSDN examples关于自己的ThreadSchedulers中使用。在MSDN description about UnsafeQueueUserWorkItem中,有一个很大的警告,即该函数可能是一个安全漏洞,并且它“不传播调用堆栈”。
唯一的链接是QueueUserWorkItem,从名称上看,哪个似乎是“安全对应的”?但也没有提到调用stacks的任何事情。
这对传播堆栈到底意味着什么?在工作开始前把它复制过来?为什么另一个线程需要调用线程的堆栈呢?我假设它们以一个新鲜而空的堆栈开始。毕竟,当线程函数返回时,它不会继续执行调度任务的函数,对吗?
发布于 2013-06-04 22:49:46
它是CAS的实现细节,代码访问安全性。它可以检查线程是否具有执行操作的足够权限。只有当代码在受限制的安全环境中运行,而不是完全信任地运行或在沙箱中运行时,才有关系。
使这项工作的管道是复杂的,我只能近似它的工作方式。ExecutionContext类是键,它决定代码运行的安全上下文。当具有受限权限的线程启动另一个线程时,情况就变得非常困难。显然,其他线程需要以与原始线程相同的限制运行。CAS依赖于能够执行堆栈遍历来发现限制。这在另一个线程上是很困难的,它有自己的堆栈。
ExecutionContext.Capture()方法在这里执行一个必不可少的角色。它复制调用线程的上下文,包括进行堆栈遍历以创建发现的安全属性的“压缩”堆栈。然后,新线程与捕获的上下文一起运行。
ThreadPool.UnsafeQueueUserWorkItem()跳过Capture()调用。线程池线程将使用默认的执行上下文运行。
这是一种优化,Capture()不是一种廉价的方法。在那种依赖于TP线程的程序中,这很重要,因为它需要匆忙完成任务。网络服务器突然出现在人们的脑海中。也是使用该方法的代码类型,例如,您可以看到它在System.Net命名空间的内部方法中使用。
显然,它是不安全的,它不使用原始线程的CAS限制运行。
https://stackoverflow.com/questions/16926106
复制相似问题