Civil question here. I am looking into an MVC project that is created from scratch/template, and I see that it makes use of asynchronous code. Specifically, I am looking at IHttpActionResult and I am curious why this returns a task on the server side.
My understanding is that asynchronous code is best utilized on the client-side when it does long-running operations so that it does not block the UI thread. On the server-side, there is no such thing, so I am curious if someone can give a quick lesson on
why this is here in the framework code and necessary. Given the threat of "zombie async" code spreading throughout my entire application, I want to limit it where possible.
Thank you for any assistance and/or insight,
what i know:
Server/framework maintains a limited number of threads for handling requests (main threads).
If your request process (ActionMethod) has a task which requires waiting because of I/O operation or compute based,
then its better to free main thread and assign this task to background thread, allowing main thread to serve other requests
which means ur webApplication scales. When background thread completes its task, it invokes main thread to let it continue the process.
Thank you for your reply. That does make sense, but I thought that already happened automatically. Do you have any resources I can look at that definitively describe/confirm this? The only resource I found was this StackOverflow Question which echoes
what you have said:
There is also this thread but it is older (and seems to confirm my suspicion that this is already handled automatically by IIS):
Try the introduction found at
http://www.asp.net/web-forms/overview/performance-and-caching/using-asynchronous-methods-in-aspnet-45 that describes how it works.
Awesome, thanks @PatriceSc. Looks like I should get used to welcoming our zombie overlords.
Although it does improve performance, it does seem like there is work for improvement in this area. Tightly-coupling code to Task and Task<T>, and decorating methods with "async" (and then also ending them with a redundant "Async") hardly seems "clean."
Not to mention the zombie-sprawl that ends up infecting an entire codebase.
Not to (again) mention all the little gotchas wonderfully outlined in this article:
It seems like this can be better handled by the framework somehow. Code just looks polluted and ugly now.
Asynchronous code has a special meaning in Computer Science. It means an asynchronous operation (usually an o/s call) that is managed by the current thread. the operation call does not block the current thread, and the call back handler must be the same
thread. this is different than parallel processing, where a new thread is dedicated to the operation. as some sort of semaphore is just to notify interested threads of the completion of the operation, in parallel processing, the original thread need not hang
around, as a completion thread can be started.
asp.net uses the parallel processing model. different stages of the request life cycle can be handled by different threads. so authentication, need not be the same thread as the one used for process.
now when the process thread performs an async operation, it can be returned to the thread pool and handle another request. this puts some restrictions on the thread when its returned to the pool, it can not timeout, and should not be killed until all pending
async operations have completed. if the async thread is processing another request, when the async operation completes, it must stop the current request, and handle the response. you want this is be as sort as possible, so you don’t want to call the handler
directly (what if the completion code took 10 seconds, then the thread would be blocked 10 seconds before it could continue processing). you want to be able to queue up the work (task) to a different thread to run the completion routine. thats why async operations
must support the task structure which allows passing the callback data to a different thread (and may require a delay while a thread is spun up).
you should only use the async tasks when you have real async operations, or just spinning up additional threads, instead of reusing a thread.
The async modifier is to generate the appropriate code for you. Ending with Async is just a convention but it seems to make sense to stress this particular method is async. It can be absused but it seems much better than how you had to do async code preivously…
Also as shown in the article youi’ll usually use this where it makes more sense (either scalability or having things that could run in parallel) rather than eveywhere you can.
I agree that it is a whole generation better than what it used to be. And I am in agreement/understanding now on the performance impact of using asynchronous functionality. This is important.
What I am suggesting is that there is more to be done in this area. For starters, "Async" isn’t even a full word. It’s promoting laziness in naming convention which is never a good practice within the developer ranks. In any case, I would like to see
this naming convention moved into classes/interfaces and not the methods themselves, as now when I poll a class through intellisense, I see its graph polluted with both synchronous and asynchronous calls. It just seems messy, dirty, and a little silly.
There just seems like there’s some further additional syntactical sugar that the compiler team can perform to really tighten this down, but unfortunately it appears I am in the minority here and everyone has jumped blindly on this bandwagon, polluted contracts