是否可以在 IIS 托管的 C++ 中启动自定义线程？ 应用？
我们在 IIS 中托管一个基于 C++ 的 WebServices 应用程序，我们发现当我们尝试启动自己的 C++ 线程时，IIS 会出现故障并崩溃。 这些线程基于 boost.thread ，它显然深入到底层的标准 Windows 线程 API。
我需要启动线程的原因是监听来自中间层服务器的多播，以保持本地缓存的最新状态。 如果没有编写另一个过程来倾听我们的声音，我不知道还能做什么。
所以问题是，这应该有效吗？ 使用 IIS 执行此类操作是否存在固有限制？
We host a C++ based WebServices application in IIS and we're finding that when we try to start our own C++ threads IIS has a fit and crashes. The threads are based on boost.thread which clearly dribbles down to the standard Windows threading API underneath.
The reason I need to start the thread is to listen for multicasts from our middle-tier server to keep local cache's up-to-date. Short of writing another process to listen for us I'm at a loss what else I can do.
So the question is, should this work? Are there inherent restrictions about doing this kind of thing with IIS?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
听起来您正在创建一个持久线程，它的生命周期比启动它的请求的生命周期长。 您没有提及它是 ASP.NET C++/CLI、托管 C++ 还是 ISAPI 扩展或过滤器，甚至 CGI。
从概念上讲，IIS 调用的代码应该仅在请求的生命周期内“存活”。 运行时间较长的代码将受到 IIS 回收应用程序池的支配。
最好的选择是使用另一个进程来监听通知，并在该进程中维护缓存。 然后，您可以使用共享内存（请参阅 Boost.Interprocess) 从您的 Web 服务访问该缓存。
It sounds like you're creating a persistent thread, which lives longer than the lifetime of the request that initiates it. You don't mention whether it's ASP.NET C++/CLI, Managed C++ or an ISAPI extension or filter, or even CGI.
Conceptually, code that is called by IIS is only supposed to "live" for the lifetime of the request. Code that runs for longer will be at the mercy of IIS' recycling of application pools.
Your best bet is to have another process that does the listening for notifications, and maintain your cache in that process. You can then use shared memory (see Boost.Interprocess) to access that cache from your Web service.
我不了解 C++，但在我的 C# ASP.NET 应用程序中，我正在创建线程并且它工作正常。 .NET 是“真正的”线程吗？ 我不知道......但它们的行为就像你希望线程那样。 也许您可以将应用程序的那部分设为 ASP.NET C#？
I don't know about C++, but in my C# ASP.NET application, I am creating threads and it's working fine. Are .NET "real" threads? I don't know... but they behave like you'd want a thread to behave. Maybe you can have just that part of your app be ASP.NET C#?
除了编写另一个进程来监听我们之外，我不知道还能做什么。
除了使用额外的线程之外，还有许多其他解决方案。 例如，轮询 + 非阻塞 IO 就是一种选择。
Short of writing another process to listen for us I'm at a loss what else I can do.
There are many other solutions than using an extra thread. Polling + nonblocking IO would be one option for example.
创建线程可能不是问题——问题在于您在该线程中所做的事情。 我将查看共享对象的代码，这些对象也由 IIS 创建的线程使用。
Creating a thread is likely not a problem -- it's what you are doing in that thread that could be. I would look at the code that shares objects that are also used by threads that IIS creates.