Is it possible to start a custom thread in an IIS hosted C++ application?

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.