ASP.NET线程池的正确使用方法是什么？
我的情况是这样的，我有一个文件会在一两个小时内慢慢填充（mp3、视频等）。当填充此文件时，许多用户连接到服务器以接收添加到服务器的新数据。
此时每个访问者连接到服务器，IHttpAsyncHandler 从线程池中分配一个线程来处理请求。然而，使用默认线程池设置，这意味着一次只有 20 个访问者可以连接到服务器（单处理器）。
因为大多数时候这些线程只是在等待新数据，所以将线程释放到池中并在新数据可用时重新激活它的最佳方法是什么。
非常感谢， 阿迪
My scenario is this, I have a file that slowly gets populated over the course of an hour or two (mp3, video, etc). As this file is populated many users are connected to the server to receive new data as it is added to the server.
At the moment each visitor connects to the server, and an IHttpAsyncHandler allocates a thread from the thread pool to handle the request. However using the default thread pool settings, this means that only 20 visitors can connect to a server (single processor) at a time.
Because most of the time these threads are simply waiting for new data, what would be the best way to release the thread to the pool, and have it re-activate when new data is available.
Many Thanks,
Ady
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我只会使用常规的
Thread来达到这个目的。 .NETThreadPool并不是真正设计来支持根据其内部状态释放和重新激活（长时间运行的）线程......至少，您必须做一些创造性的工作如果您坚持使用ThreadPool（即将逻辑分解为由ThradPool执行的小型异步任务），则可以通过编程来实现所需的行为。如果您使用
Thread，那么您将可以直接控制所有活动线程，这样您就可以同时接受更多访问者。I would just use regular
Threads for this purpose. The .NETThreadPoolis not really designed to support the releasing and re-activation of (long-running) threads depending on their internal state... at the very least, you would have to do some creative programming to achieve the desired behavior if you stick with aThreadPool(i.e. break the logic into small asynchronous tasks that get executed by theThradPool).If you go with
Thread, then you will have direct control to all the active threads so you can accept more visitors at the same time.F# 有一个名为异步工作流的功能，非常适合这种类型的东西。当您的代码正在等待外部数据源时，线程将返回到线程池以供其他用途。当新数据到达时，工作流会从池中获取一个线程，并使用它从上次中断的地方恢复代码。通过这种方式，您永远不必占用一个除了等待 I/O 之外什么都不做的线程。
仅仅为了这个用途而学习一门新语言可能有点大材小用，但在异步 I/O 方面，F# 优于所有其他 CLR 语言，而且它是一种非常有趣的语言。
F# has a feature called Asynchronous Workflows that is ideally suited to this sort of thing. When your code is waiting on an external data source, the thread is returned to the thread pool for other uses. When new data arrives, the workflow gets a thread out of the pool and uses it to resume your code where you left off. In this way you never have to tie up a thread that's doing nothing but waiting on I/O.
It may be overkill to learn a new language just for this one use, but F# towers over every other CLR language when it comes to async I/O, and it's a really fun language, besides.