Sarbacher: Leverson, did i unlock a badge of some sort for being able to understand that
Gull: Harju: the important thing to recognise is that in normal, synchronous code, the caller of a function is paused until the function returns; but when an operation could take tens, hundreds, even thousands of milliseconds to complete, you don’t want everything blocked for that long
Bosche: Gull, so does this only apply on node.js?
Harju: I know callbacks save a lot of processing time deltab
Gull: Games: event loops? they’re in all sorts of systems
Crepps: Gull, true, i just never think about the browser as “the” event loop
Gull: Harju: so an asynchronous function starts something going, then returns immediately. Obviously the result isn’t available at that moment so it isn’t returned
Harju: A promise waits for an event to be emitted and consumes it?
Harju: And that’s how I can get my result out of my callback?
Hitchman: The way I see it, and correct me if I’m wrong, and don’t get too es6’y with me just yet, is that everything is running synchrnously except for a few magic functions that the underlying system allows you to run async
Harju: Sounds really similar to socket programming
Gearing: Harju: mmm, probably not a good way to look at it
Gearing: Harju: you don’t get things “out” of callbacks
Gearing: Harju: you p*** them on to the next thing that needs them.
Gearing: Promises were invented for network programming :
Gull: Harju: there’s no waiting, and there’s no way to get the value out
Harju: So I can’t have my value emitted from the callback and consumed by a waiting promise?
Gull: But promises give you something to p*** aroudn in lieu of a value
Gearing: Harju: promises don’t “wait”
Liptrap: Network programming is like any other generic async operation. there is nothing special about networks.
Ornelaz: Games: more accurate to say that everything runs synchronously always, but the underlying system will sometimes call back into your synchronous code sometimes.
Gearing: Zap0: everyone says there’s nothing special about networks. until the wifi goes down
Harju: Ok so sockets can wait, like socket.listen, but promises don’t. L
Gull: Harju: and a callback can be attached to the promise that’ll receive the value when it’s available
Ifft: Tcsc, so more or less, this part of js is all about peeling back the “single-threaded” charade
Ornelaz: It is single threaded
Bendick: The javascript is single threaded but what it results in is not
Gull: Harju: what do you call socket.listen with?
Ornelaz: Unless i’m mistaken, you could implement node and its runtime with one thread.
Harju: That’s Java code Gull, sorry for the confusion
Ornelaz: It just wont always be running.
Ornelaz: The browser needs multiple threads though
Ornelaz: And node certainly has multiple threads
Gull: Harju: ah, so in java that’d block the thread?
Ornelaz: But those are transparent to you
Arcangel: How could you implement node in one thread? unless everything blocked is what you mean
Gull: Games: with an event loop: execute a small piece of the program, not pausing for anything, and recording callbacks for when responses come back; then, whenever the current executing code returns to the event loop, check whether something’s happened
Breske: Games: it’s still single-threaded.
Winnie: Games: if you’re asking about implementation, POSIX has select or poll for figuring out what fds you can read/write from/to without waiting.
Holl: Gull, watching the philip roberts talk
Gull: Call the event handlers, then return to the loop
Harju: Yeah Gull. Last quarter I wrote a multithreaded socket application in java client/server programming, where the server would block, waiting for connections. Whenever it received one, it’d spawn a thread on the server side to talk to the client. Then the server and client would set up their streams and both block, waiting for eachother to send things. It was a lot of learning for me