Async might be a fad • Hacker News Board

Re: Async might be a fad

#31

Post by virmundi » Tue, Aug 05, 2014, 10:07 PM UTC

zhong-j-yu wrote: post #23

virmundi wrote: post #15

Seems like as a good a time as any to refresh people's ideas on Java. There is a user-thread implementation for Java. It does require instrumenting the bytecode, but it does work. http://docs.paralleluniverse.co/quasar/ . I'm looking at the port of Quasar to Clojure as my sole reason for looking at Clojure over Erlang.

I absolutely love Quasar. Nevertheless, there's an honest question whether it is actually needed in majority of applications. I think not.

The thing I like about it is that you get the async possible benefits without the logical overhead. Erlang allows many connections to queue up on a web server. Now Java can too.

I think if done right, this will bring down costs for scaling. I recently looked at Linode and AWS. My first thought was holy crap! To get a small 2 GB Ram box is rather expensive. It would be cheaper to just pay for a business internet connection and host my own boxes. If I had a spike in connection with normal threading on a small box (my laptop with 16 GB), Java would start to sputter around 200 threads due to context switching. Connections would be rejected. Quasar server would accept the connections, just have a high latency. I could live with that.

Re: Async might be a fad

#32

Post by zhong-j-yu » Tue, Aug 05, 2014, 10:11 PM UTC

nmjohn wrote: post #29

twerquie wrote: post #16

If your application is largely fetching a bunch of external resources, say from something slow like a database or a web API, mashing them up and returning a response to a client, you need async. Node has a very beginner-friendly primitive for doing this.

Yes. People in general are really bad at grasping the concept that $programming_paradigm are not all equally suited for a given problem. Object Oriented, functional, async, strict type system, etc. I've noticed an almost evangelical nature of people in trying to push their prefered environment on others. Guess what? Node.js is not the answer to everything (and I do 90% of my work in node!). But you know what? Neither…

I agree that external IO most likely would benefit from async. But, we don't need to turn the entire request-response code flow into async style, just because of one async call. We could break it up into 3 parts: sync code, async code (for external IO), sync code again.

Re: Async might be a fad

#33

Post by cpeterso » Tue, Aug 05, 2014, 10:14 PM UTC

zhong-j-yu wrote: post #27

vampirechicken wrote: post #25

I hope somebody told the poster about putting a proxy server (squid, apache, nginx, varnish, etc.) between the application server and the client. Proxy deals with slow client delays. App server serves app requests at speed. Tune number of proxy connections to keep app servers reasonably busy. Scale each layer individually. IMO Whether the proxy is async or not is a matter of taste.

I would rather buffer the entire response in the app server, instead of in the central reverse-proxy.

Why buffer on the app server?

Re: Async might be a fad

#34

Post by __david__ » Tue, Aug 05, 2014, 10:16 PM UTC

The select() loop has been a core part of unix since before many people here were born. That's the basis of async, evented IO—it's hard to call that a fad.

Perhaps the callback mechanism of Node is a fad—continuation based techniques can make async code look like non-async code. Perl's Coro and Ruby's new(ish) fibers are examples of how that could look.

Re: Async might be a fad

#35

Post by cpeterso » Tue, Aug 05, 2014, 10:16 PM UTC

gamegoblin wrote: post #17

zhong-j-yu wrote: post #12

Earlier quoted context omitted.

Yes, if you have light-weight threads, there's no question that threaded programming is better than async programming. But we are talking about heavy Java thread, and whether its cost is so high that we need to avoid threaded programming. I think the answer is no, generally. Also, the discussion is in the context of imperative programming.

Funnily, Java's original threads (back in 1997) were green threads, but they got dropped in favor of native threads.

Rust supports both native and green threads, but defaults to native threads.

Re: Async might be a fad

#36

Post by m0th87 » Tue, Aug 05, 2014, 10:17 PM UTC

This is a straw man argument. Async doesn't have to look like node.js' callback hell - that's what go, erlang and several other languages achieve with M:N green threading.

Re: Async might be a fad

#37

Post by zhong-j-yu » Tue, Aug 05, 2014, 10:20 PM UTC

MaulingMonkey wrote: post #28

zhong-j-yu wrote: post #9

Earlier quoted context omitted.

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.

"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…

There 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.

Re: Async might be a fad

#38

Post by orclev » Tue, Aug 05, 2014, 10:20 PM UTC

zhong-j-yu wrote: post #32

nmjohn wrote: post #29

Earlier quoted context omitted.

Yes. People in general are really bad at grasping the concept that $programming_paradigm are not all equally suited for a given problem. Object Oriented, functional, async, strict type system, etc. I've noticed an almost evangelical nature of people in trying to push their prefered environment on others. Guess what? Node.js is not the answer to everything (and I do 90% of my work in node!). But you know what? Neither…

I agree that external IO most likely would benefit from async. But, we don't need to turn the entire request-response code flow into async style, just because of one async call. We could break it up into 3 parts: sync code, async code (for external IO), sync code again.

In some code I wrote for a major corporation who will not be named, that's pretty much exactly what was done. We would use a thread pool to spin off a bunch of workers given Future instances to chew on, and then we'd just block waiting for all the results to come back before returning to the client. The thread that handled a request was synchronous to the client, but did all its services requests async and in parallel. Where appropriate we'd also chain things, so one batch of async requests would go out, the results would be gathered and then those results would be used to generate a new batch of async requests, which one again would be gathered and the results used to respond to the client. For those keeping track, this is basically the lazy IO pattern. Not async in the sense of nodejs (which I hate by the way), no callbacks, rather we get a collection of thunks which we can block on evaluating.

Re: Async might be a fad

#39

Post by dragonwriter » Tue, Aug 05, 2014, 10:21 PM UTC

gamegoblin wrote: post #17

zhong-j-yu wrote: post #12

Earlier quoted context omitted.

Yes, if you have light-weight threads, there's no question that threaded programming is better than async programming. But we are talking about heavy Java thread, and whether its cost is so high that we need to avoid threaded programming. I think the answer is no, generally. Also, the discussion is in the context of imperative programming.

Funnily, Java's original threads (back in 1997) were green threads, but they got dropped in favor of native threads.

IIRC, Java's original threads were N:1 green threads, while the lightweight threads in Haskell discussed above are M:N green threads. N:1 is easier to implement, and fine for single core systems, but doesn't give you real parallelism. M:N, like 1:1 native threading, gives you real parallelism, but also, like N:1, cheap concurrency (at the expense of being the hardest to implement well.)

Multicore processors and the fact that single-threaded performance basically hit a wall explains why an N:1 threading models in something with the use cases of Java fell out of favor. M:N, while still "green threads", has a somewhat different set of trade-offs versus 1:1 native threads than N:1 does, though.

Re: Async might be a fad

#40

Post by zhong-j-yu » Tue, Aug 05, 2014, 10:24 PM UTC

__david__ wrote: post #34

The select() loop has been a core part of unix since before many people here were born. That's the basis of async, evented IO—it's hard to call that a fad. Perhaps the callback mechanism of Node is a fad—continuation based techniques can make async code look like non-async code. Perl's Coro and Ruby's new(ish) fibers are examples of how that could look.

what I meant is whether it's a fad to spread async everywhere inside application code, and call that a good thing. the computer is of course async in nature; but the abstraction on the app layer does not have to be.