4 ms·
Seems like you're looking at it solely from a web server/application back-end perspective. Async I/O and the corollary, freeing up threads, is useful in lots of
by curiousDog 12y ago
Seems like you're looking at it solely from a web server/application back-end perspective. Async I/O and the corollary, freeing up threads, is useful in lots of other places like UI or applications that require very low latencies (We had a distributed process that had to respond to heart-beat requests from other machines amongst other I/O bound requests. Tying up threads when doing I/O would've been a death sentence).
- zhong-j-yu 12y agoUI - of course the UI thread should not be blocked in handling IOs. My point is, move these IO actions to another thread; the code in that thread is good old synchronous/threaded code. heart-beat - yes we'll need concurrent threads for handling concurrent requests in the blocking world; the question is whether this will result in too many threads, which depends on the application.
- MaulingMonkey 12y ago"My point is, move these IO actions to another thread; the code in that thread is good old synchronous/threaded code." Sure. But how do you handle that? IO results need to be communicated back to the UI thread somehow. Throwing together a whole new thread+stack against a named method that communicates back via explicit messages (or however you want to get the results of IO back to the UI thread) seems like a bit much if all you want to do is download a motd.txt and stuff it in a label.
- zhong-j-yu 12y agoThere is no problem to modify UI state from any thread; just put up some synchronizations. The hard part is, if the modifications do not form a single, predictable, serialized chain, how can the programmer reason about them? This problem is independent of async/sync. If you use C# async for a UI action, you still need to worry about it.
- kaoD 12y ago> There is no problem to modify UI state from any thread; just put up some synchronizations. It reminded me of the "I know, I'll use regular expressions" joke.
- zhong-j-yu 12y agoThe single-event-thread design is not without its own problem; programmers have difficulty in understanding and abiding to it too. Here we have an inherently concurrent problem - user actions and some IO actions occur concurrently. That problem cannot be reduced by some API or language trick.
- kaoD 12y ago> The single-event-thread design is not without its own problem; programmers have difficulty in understanding and abiding to it too. Definitely not my experience. jQuery is very popular among unskilled programmers because its async model is very easy to understand. I use it to teach async! > That problem cannot be reduced by some API or language trick. Why? Reducing problem by API or language tricks is exactly what abstraction is for.
- fleitz 12y agoGiven the Universal Turning Machine and the Church-Turing thesis in actuality all of programming except for assembler is pretty much some API or language trick.