如何从 CLR 线程池而不是 ASP.NET 池在 ASP.NET 页面中创建线程？
如果我在 ASP.NET 页面上创建一个新线程，则 IsThreadPoolThread 属性为 true。 第一个问题是，它是来自 ASP.NET 池还是 CLR 池？ 第二个问题是，如果它来自 ASP.NET 池，那么如何从 CLR 创建线程而不使用 ASP.NET 池？ 我需要一个针对长时间运行的请求的同步解决方案（
If I create a new thread on an ASP.NET page the IsThreadPoolThread property is true.
First question is, is it from ASP.NET pool or CLR pool ?
Second question is, if it is from ASP.NET pool then how to create a thread from CLR and don't use ASP.NET pool ?
I need a synchronous solution for long-running requests (full story).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
首先，ASP.NET 线程池和 CLR 线程池之间没有区别。 ASP.NET 在 CLR 线程池上处理页面，因此您的 ASP.NET 页面将始终具有 IsThreadPoolThread == true。
我很好奇你是如何创建你的线程的。您使用的是 System.Threading.Thread 构造函数，还是使用 ThreadPool.QueueUserWorkItem？如果您使用 ThreadPool.QueueUserWorkItem，那么您获得的线程来自常规 .net 线程池。
最后，正如我之前发布过的那样，这始终是一个坏主意尝试从 ASP.NET 中运行长时间的任务。我的一般建议是使用后台 Windows 服务来处理这些请求，因为 ASP.NET 可能随时终止您的后台线程。更多详细信息这里，如果您必须在 IIS 中执行此操作。
First off, there is no difference between the ASP.NET thread pool and the CLR thread pool. ASP.NET processes pages on the CLR thread pool, so your ASP.NET pages will always have IsThreadPoolThread == true.
I'm curious as to how you are creating your thread. Are you using the System.Threading.Thread constructor, or are you using ThreadPool.QueueUserWorkItem? If you are using ThreadPool.QueueUserWorkItem, then the threads that you are getting are coming from the regular .net thread pool.
Finally, as I have posted before, it is always a bad idea to attempt long running tasks from within ASP.NET. My general suggestion is to use a background windows service to process these requests, since ASP.NET may terminate your background thread at any point. More details here, if you must do it in IIS.
虽然需要强调的是尽量减少对事务的影响并满足分布式事务中不可预见的情况，但在本例中，确实没有必要仅仅因为该进程运行时间较长就重新发明 IIS。整个“IIS 随时可能死亡”的模因恕我直言，被大大夸大了。
是的，您可以手动重新启动 IIS 或应用程序池，但您也可以重新启动任何其他执行相同作业以获得相同效果的服务。至于自动回收，IIS 使用重叠的工作进程，并且永远不会强制终止已启动的线程（除非发生超时）。如果是这种情况，我们的任何托管应用程序都会遇到严重问题（如何阻止 IIS 在启动后 0.001 毫秒杀死快速响应线程）
本质上，让 IIS 做 IIS 最擅长的事情，而不是坚持同步操作，你只会浪费池的线程来等待阻塞 I/O，我相信这是你试图避免的。您已经通过异步处理程序 (ASHX) 做出了不错的选择，使用 IHttpAsyncHandler 实现来生成自定义线程，该线程将在不影响 Web 应用程序及其池的情况下满足您的需求。一旦启动异步操作线程，asp.net 线程将返回到其自己的池并准备好开始服务新请求。池中默认限制为 100 个线程，并且考虑到您的进程是低 CPU 高带宽的，我怀疑在耗尽管道空间之前您不会用完池线程:)。有关如何构建异步处理程序的更多信息，请检查此链接（这是一篇旧文章，但仍然有效）：
在服务器端 Web 代码中使用线程并构建异步处理程序
While there is a point to be made about minimizing impact on transactions and catering for the unforeseen in distributed transactions, in this example its really not necessary to reinvent IIS just because the process is long running. The whole "IIS can die at any moment" meme is IMHO greatly exaggerated.
Yes, you can manually restart IIS or app pool but so can you restart any other service which does the same job for the same effect. As for auto-recycle IIS uses overlapping worker processes and will never terminate a started thread forcefully (unless time out occurs). If that were the case we would have serious problems with any hosted application (what's to stop IIS from killing a fast response thread 0.001ms after start)
In essence, let the IIS do what IIS does best and don't insist on sync operation, you'll just waste pool's thread waiting for blocking I/O which is what I believe you are trying to avoid. You already made a good choice by going to Asynchronous Handlers (ASHX), use
IHttpAsyncHandlerimplementation to spawn your custom thread which will then block to your heart's desire without affecting the web application and its pool. Once you initiate an async operation thread the asp.net thread will go back to its own pool and will be ready to start serving a new request. With a default limit of 100 threads in a pool and given that your process is low-on-cpu-high-on-bandwidth I doub't you'll ever run out of pool threads before you run out of pipe space :). For more information on how to build async handler check this link (its an old article but valid non the less):Use Threads and Build Asynchronous Handlers in Your Server-Side Web Code
事实上，ASP .NET 中的线程是有区别的：工作线程和 IO 线程（系统线程，我相信您将其称为 CLR 线程）。
现在 ASP .NET 在每个请求上使用一个工作线程，除非使用自定义配置，并且这些工作线程受到 CPU 数量的限制；可以在 IIS 中设置此配置。
例如，当您在 ASP.NET 中使用委托启动异步任务时，您正在使用另一个工作线程。委托是在 .NET 中启动异步事物的一种快速而肮脏的方式:)
如果您想启动一个不耗尽工作线程的新线程，那么您必须显式启动一个新线程，例如：new Thread()... 。ETC。现在它带有大量代码管理，并且不遵循基于事件的异步模式。
然而，有一种方法可以安全地启动异步线程，那就是在对象上使用 .NET 自己的异步方法。您通常会使用异步执行 SQL 命令、Web 服务调用等操作。所有这些都有 BEGIN 和 END 方法。
通过使用这些方法，您将永远不会使用工作线程，而是使用 IO 线程。
当涉及到异步页面时，ASP .NET 有一些技巧。
有两种选择：
我不知道所有详细信息，但请查看 MSDN 库上的两个选项。
这是关于该主题的文章： 异步编程
There is in fact a difference in threads in ASP .NET: Worker threads and IO threads (system threads which i believe you state as CLR thread).
Now ASP .NET use a worker thread on each request, unless custom configurations are used, and these worker threads are limited on your CPU number; this configuration can be set in IIS.
When you start an asynchronous task inside ASP.NET by using delegate for instance, you are using another worker thread. Delegates are a quick and dirty way of starting something asynchronous in .NET :)
If you want to start a new thread which does NOT use up a worker thread, then you must explicitly start a new thread like: new Thread()....etc. Now this comes with alot code management, and does not follow the event based asynchronous pattern.
However there is one way you can start asynchronous threads safely and that is by using .NETs own asynch methods on objects. Things you normally would use asynch for like SQL commands, webservice calls, etc. All these have a BEGIN and an END method.
By using these methods you will never use a worker thread, but an IO thread.
ASP .NET has a few tricks up its sleeve when it comes to asynchronous pages.
There are two alternatives:
I dont have all the details, but please look into the two options on MSDN Library.
Here is an article on the subject: asynch programmin