views:

116

answers:

4

Hi all

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?

Thanks

A: 

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

Corey Trager
A: 

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.

Leon Timmermans
A: 

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.

Lou Franco
+2  A: 

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.

Sunlight
Sunlightd: you have hit the nail on the head. The thread needs to live longer than the request itself, and you say this is not possible? It's a pure C++ thread btw.So yes, I already use boost.interprocess for IPC...looks like another process is needed.
jkp