On 9/11/07, Konstantin Triger <[EMAIL PROTECTED]> wrote: > The feature actually consists of 2 sub-features: > 1. Runtime support (Page API). > 2. Aspx parser support. > > Several months ago we completed (1). So currently someone needs to ensure (2) > works too. > While implementing it, we did not find any really useful scenario why someone > may need this feature. Can you please explain what your use case is?
Hi Kosta, the scenario is the same as with async web services - to free a threadpool thread not to be used for a long term operations. I have a web page (I can use web service, but it returns a blob of 1M binary data, so with soap, etc, it will be at least doubled) which returns a blob of binary data, which is collected after a lot of web service and database requests in different threads (async, so io threads from the thread pool). When you have too many incoming requests, which block for a long time thread pool threads, and in the same time your execution occupies thread pool threads for the outgoing requests, the result may be a dead lock, and dropped requests, because no one knows the order of thread assignment (i.e. the order in which you will receive incoming requests, and when your own requests will start). As elementary example (thread pool with only 4 threads): - receive first request and block untill finish - 3 in the pool - receive sec. request and block - 2 in the pool - first req. starts 3 own threads to get data - they in term need 3 thread pool threas - 2 are available, and one queued - third request is received, and queued (not pool threads) - forth request is received, and queued (not pool threads) - fifth request is received, and queued (not pool threads) - second req. starts 3 threads as well, and the framework queues them - one of the requests from the first request is finished and thread pool thread is freed - it is assigned to the third call made by the first request - next req. finishes, and the thread is assigned to the third incoming request, and block, because its processing stops to wait thread pool threads (3 of them). - now, when the 3th thread from the first incoming is finished, it will go to the forth incoming request and blocked now you have your thread pool blocked on requests, which in terms wait on the tread pool. Eventually this will end with some time-outed requests, but may end with really bad dead lock. That's why using async web services is good for such a scenario, and because I need web page instead web service, I need the async approach. Of course, there are online some examples how to do this with 1.1 and creating your own aspx handler, so you make the call async. And, of course, maybe I can rethink the design. But lets say that this is the approach which serves me best. Basically, I have the application, implemented for 2.0, and now I just have to decide what server to use - win or linux. And I would prefer linux. So, maybe I'll go with some of the workarounds, i.e. to implement my own handler, or I may wait some time, if this is planned feature. For reference: <http://msdn.microsoft.com/msdnmag/issues/05/10/WickedCode/> And this is a comparison in the performance when using async vs sync pages, when the page logic makes a lot of async requests itself: <http://www.pluralsight.com/blogs/fritz/archive/2004/10/19/2892.aspx> Pls, note, that I could not find the original article I read about the dead blocking scenario, so I just tried to reproduce it (maybe inaccurate). Cheers -- Svetoslav Milenov (Sunny) Even the most advanced equipment in the hands of the ignorant is just a pile of scrap. _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
