4 ms·

Those are my thoughts; I'd like to hear counter arguments.

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 ago
  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.
  - 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 ago
      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.
      - 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 ago
        The 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 ago
        Given 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.
        dllthomas 12y ago
        Arguably, even machine language is "some API" and assembler "some language trick".
        fleitz 12y ago
        Good point, I forgot for a second that the CPU turns assembler into microcode before executing it.
com2kid 12y ago
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.
korzun 12y ago
Maybe I'm looking at this from a different perspective. Some implementations do not require any response. For example if I have a honey pot that collects random events, the clients can just send the data to it without expecting a result (IE: I don't care if it's successful or not) and honey pot is not expected to write any sort of response. Clients send data and move on.
- zhong-j-yu 12y ago
  I agree, async is needed sometimes. Another example, a server broadcasts an event to multiple clients (e.g. a chat app), it would be silly to spawn a thread per client for that.
  - syntheticlife 12y ago
    Or, sometimes you have to serve 10k pages at once. http://www.kegel.com/c10k.html http://www.kegel.com/c10k.html
  - korzun 12y ago
    But the whole point of async is that, after data is dispatched the client moves on. I'm not sure what NodeJS does with it but this is my interpretation of the concept. I don't think people who know what they are doing, use async calls for mission critical operations. If async call returns response and client is required to read the response it's no longer considered non-blocking from technical perspective.
    - deleted 12y ago
      [deleted]

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 ago
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.
- 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 ago
    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.
    - 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 ago
        The 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 ago
        Given 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.
        dllthomas 12y ago
        Arguably, even machine language is "some API" and assembler "some language trick".
        fleitz 12y ago
        Good point, I forgot for a second that the CPU turns assembler into microcode before executing it.

com2kid 12y ago

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.

korzun 12y ago

Maybe I'm looking at this from a different perspective. Some implementations do not require any response. For example if I have a honey pot that collects random events, the clients can just send the data to it without expecting a result (IE: I don't care if it's successful or not) and honey pot is not expected to write any sort of response. Clients send data and move on.

zhong-j-yu 12y ago
I agree, async is needed sometimes. Another example, a server broadcasts an event to multiple clients (e.g. a chat app), it would be silly to spawn a thread per client for that.
- syntheticlife 12y ago
  Or, sometimes you have to serve 10k pages at once. http://www.kegel.com/c10k.html http://www.kegel.com/c10k.html
- korzun 12y ago
  But the whole point of async is that, after data is dispatched the client moves on. I'm not sure what NodeJS does with it but this is my interpretation of the concept. I don't think people who know what they are doing, use async calls for mission critical operations. If async call returns response and client is required to read the response it's no longer considered non-blocking from technical perspective.
  - deleted 12y ago
    [deleted]