This isn't just one thread for all users, but one thread per user via the tracking session cookie.
Still - STA is very very inefficient for IIS to process.
If you run your same sample with multiple browsers (ie. separate sessions) then you should see the sleep not effect the other session.
I'm using VS 2012/.NET 4.5 and experimenting with ASP.NET and FoxPro COM objects, trying to learn exactly how.NET/IIS handles associated threads. I have set AspCompat="true" in the page as directed. According to what I've read, requests are scheduled to an STA Thread Pool, but there is no explanation of how the thread pooling works. In my testing, it appears to be one thread per user session. If a user has two tabs open in their browser, these share the same session and hence the same thread. A running AspCompat request on one tab will block AspCompat requests on the second tab. For example, add a button to a web form and put the following code in the click event:
protectedvoid Button1_Click(object sender, EventArgs e)
{
System.Threading.Thread.Sleep(5000);
Response.Write("ASP.NET Thread " + System.Threading.Thread.CurrentThread.ManagedThreadId.ToString());
}
Be sure to set AspCompat ="true" in the page, then run the app and open the page in two tabs. Click the button on the first tab, then quickly switch to the second tab and click the button. You'll notice the first tab request has to complete before the second tab request starts, and afterwards the page reports that both requests ran on the same thread. Set AspCompat = "false" and rerun the tests. This time both requests run simultaneously and in different threads. At least this is what is happening in my tests.
Is this all by design? I know you need to use AspCompat for COM interop, but a user ought to be able to perform multiple tasks in multiple tabs like a normal web page, don't you think? Is there a configuration setting to modify this behavior?
Thanks,
Joel