2 ms·
agreed, doesn't waiting for request to finish completely before sending response imply synchronous not async?
by etherealG 17y ago
agreed, doesn't waiting for request to finish completely before sending response imply synchronous not async?
- axod 17y agoyes, which is a silly way to program. I'm not sure why there's any confusion :/ == Sync == Thread 1: Do A -> block -> Do B Thread 2: Do C -> block -> Do D eg Tell the OS to execute your code in random order, then build a ton of code to cope with that. == async == while(true) { // do some of A, or if that's complete, do some of B // do some of C, or if that's complete, do some of D }
- sparky 17y agoI'm still not sure I follow. Where does the "ton of code" come in? The boilerplate code around spawning new threads? The painfulness of that task varies widely amongst OS-level threading primitives, user-level thread libraries, and other programming models that let you do tasks with dependences like Cilk http://supertech.csail.mit.edu/cilk/ http://supertech.csail.mit.edu/cilk/ or TBB http://www.threadingbuildingblocks.org/ http://www.threadingbuildingblocks.org/ . Personally, if I have a DAG of tasks to do, I prefer to encode that DAG in the structure of my code by breaking independent chains into separate tasks/threads/whatever and feeding that to some piece of software to do the scheduling for me, rather than roll my own scheduling in a potentially bug-prone and unscalable way. For the example shown, either is perfectly fine, but if you have hundreds of outstanding jobs with a more complex dependence structure, I'd rather not deal with scheduling myself.