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?
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.