views:

24

answers:

1

In an async http handler, we add items to the ASP.NET cache, with dependencies on some files. If the async method executes on a thread from the ThreadPool, all is fine:

AsyncResult result = new AsyncResult(context, cb, extraData);
ThreadPool.QueueUserWorkItem(new WaitCallBack(DoProcessRequest), result);

But as soon as we try to execute on a thread out of the ThreadPool:

AsyncResult result = new AsyncResult(context, cb, extraData);
Runner runner = new Runner(result);
Thread thread = new Thread(new ThreadStart(runner.Run());

... where Runner.Run just invokes DoProcessRequest,

The dependencies do trigger right after the thread exits. I.e. the items are immediately removed from the cache, the reason being the dependencies.

We want to use an out-of-pool thread because the processing might take a long time.

So obviously something's missing when we create the thread. We might need to propagate the call context, the http context...

Has anybody already encountered that issue?

Note: off-the-shelf custom threadpools probably solve this. Writing our own threadpool is probably a bad idea (think NIH syndrom). Yet I'd like to understand this in details, though.

A: 

Could not figure out the details... Found a workaround, though: in most IAsyncResult implementation, once the operation is completed there is a direct call to the callback. We replaced this, and now queue the callback into the ThreadPool. Hence, the callback executes within the ThreadPool and can register dependencies that last.

Stephen