Async might be a fad
cs.oswego.edu
Async might be a fad
1–10 of 76 posts
Re: Async might be a fad
#2Those are my thoughts; I'd like to hear counter arguments.
Re: Async might be a fad
#3Those are my thoughts; I'd like to hear counter arguments.
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).
Re: Async might be a fad
#4[deleted]
Re: Async might be a fad
#5Async computation is not the fad, it's poor syntax is.
C#, F# and coffeescript have excellent syntax that remove the line noise caused by writing async code. Actors and channels also nicely remove line noise from async programming.
If anything as computers become more powerful and distributed you'll see threads and locks disappear rather than async computation. Async computation in an imperative style is what most want, threads and locks are what we have.
Re: Async might be a fad
#6I'm currently hacking on a toy webserver in Haskell, and from my point of view, I spin off a thread for each request, but Haskell's runtime environment manages all of these as a group of green threads doing aynch IO behind the scenes. Best of both worlds as far as I'm concerned.
I just change
serve request forkIO (serve request)
Re: Async might be a fad
#7Those are my thoughts; I'd like to hear counter arguments.
My team is using a home made async framework in an embedded project right now, straight C. Suffice to say we all miss the syntactic sugar, but not having things like an MMU or wanting to pay the overhead for a proper threading system means that using an async type system made a lot of sense.
It is a powerful programming model that unfortunately quickly devolves into spaghetti code if not carefully maintained, but properly done it is quite nice and alleviates a ton of worries about synchronizing threads.
Re: Async might be a fad
#8[deleted]
Re: Async might be a fad
#9Those are my thoughts; I'd like to hear counter arguments.
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)…
UI - 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.
Re: Async might be a fad
#10"There's a dilemma though - if the application code is writing bytes to
the response body with blocking write(), isn't it tying up a thread if
the client is slow?"
There are TCP buffers. If it gets full ya maybe you'll wait a bit but it's thread vs rope relative to blocking a whole big roundtrip data exchange while blocking a thread. Nobody really tunes the write buffers because it doesn't slow down our apps. That is not the case with calls to remote services.
Note that TCP buffers are pretty big so the chance of the thread blocking while writing are very low.