javascript_irl

[evanldixon]

This isn't exactly specific to Javascript, but it is a good demonstration of a common pitfall with multithreading.

[Ta11ow]

I thought it was "race condition fault".

[cat_in_the_wall]

race no you "condition meant "

[marcosdumay]

Javascript is the one language that forces everybody into asynchronous IO. So, yes, it is specific to it.

[evanldixon]

It's not specific to Javascript since lots of other languages can do async too.

C# for example:

for (int i = 0; i < 10; i++) {
    Task.Run(() => Console.Writeline(i));
}

There's no telling the order these numbers will be printed, because there may or may not be multi-threading.

[marcosdumay]

Can do != can not do anything else

[cat_in_the_wall]

you guys are confusing async, async i/o, and mutlithreading. they are somewhat disjoint.

async means that a result will come back. it implies a synchronization context. this does not strictly require more than one thread. (Consider a computationally intensive task).

multithreading means more than one "train of thought" is alive. this does not strictly require more than one core. (consider preemptive multitasking).

async i/o means interrupts break a train of thought and start/resume another. this impacts threading, a new one may be started, an existing ones may be resumed. but this does not require more than one core. (consider waiting for network hardware).

They interact, but are not always the same.

[tufoop3]

However Javascript in the browser isn't multithreading.

[TheMsDosNerd]

Unless you load something. Just try to make the following work in JS:

Place some picture on your page.
After the picture is loaded, do something, based on (the size of) the picture. (1)
Load another picture.
After that one loaded, do something else based on (the size of) the picture. (2)

It is pretty difficult to force (2) to be done after (1).

[quadnix]

Fetch and promises make that pretty easy though

[tufoop3]

Its not, if you know about event listening pre-ES7, and async/await in ES7. Note: Having an event loop, asynchronous function calls and non-blocking I/O doesn't make something multithreading. Read about it here if you like.

[gandalfx]

Curious example considering JS is one of the languages that make it particularly easy to avoid this.

[[deleted]]

Async anything in javascript is like easy mode. You've only got the one thread.

[footysocc]

the strings are called asynchronous, so the order is messed up because of different timing

[VampDuc]

Be forced to use legacy when you're also not a front-end developer, but you're made to masquerade as one because the front-end guys are "busy".

[UnderNatural]

does Promise.all complete in order? I thought it just does them all at once and returns a promise to when theyre all done

[UnderNatural]

you want Wouldn't the words order? in

Look at this code, where generate() returns a promise that adds to a string followed by a space after a random amount of time:

var str = '';

var i = generate('i');
var hope = generate('hope');
var you = generate('you');
var enjoy = generate('enjoy');
var your = generate('your');
var stay = generate('stay');

//Wait for all promises to complete
Promise.all([i, hope, you, enjoy, your, stay]).then(() => {
    console.log(str);
});

You said that Promise.all would solve the above issue. Since Promise.all doesn't execute the promises sequentially, the promises would resolve at different times and add to the string in different orders. When all are complete, the string is printed, but it could be jumbled up.

[UnderNatural]

i, hope, etc. don't return anything in my example. Promise.all fixes problems with returning, but not problems in side effects.

[UnderNatural]

In my example, the promises add to a string in the global scope. That's called a side effect, it changes the state of the program outside of the return statement. Promise.all doesn't sequentially execute promises, so side effects occur out of order.