Yeah Gull. Last quarter I.

 
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