Develop Reference

Why does Javascript have much fewer blocking functions than Python

Moving from Javascript to Python, and looking at asyncio has me a little confused.
As someone who is new to the fundamental concepts of concurrency, I just assumed a superficial understanding of Javascript concurrency.
A basic understanding from using async / await in Javascript:
If we run any processes inside an async function, and await the response of the function, we are essentially waiting for the function to set a value on the Promise.
Makes total sense - when the Promise is given a value, we can also use callbacks such as .then() to handle the response. Alternatively, just await.
Whatever the underlying implementation of asynchronicity here is (for example all processes running on a single thread with an event loop), should it matter how we interface with it?
Now, I move to Python and start playing with asyncio. We have Futures, just like Promises. All of a sudden, I can't use my standard libraries, such as request.get(...), but I need to use non blocking network requests in libraries such as aiohttp.
What does blocking / non-blocking mean here? I assume it means the single thread that the event loop is on is blocked, so we cant process other functions in parallel.
So my 2 questions then are:
What causes the single thread to be blocked? For example in requests.get(...)
Why are most functions non-blocking in Javascript, but not in Python (i.e we don't need specific libraries such as aiohttp).
And what about languages like Go with their goroutines? Is it just a case because its a new language with concurrency built in from the beginning, that the concept of blocking functions don't exist. Or in Go it's not a single thread, so everything can inherently be parallelised?
Thanks :)

Event loop
Javascript, and python's async io make use of a concurrency model based on event loops.
(Note the plural because you could have multiple event loops which handle different kinds of tasks e.g. disk io, network io, ipc, parallel computations etc)
The general concept of an event loop is that, you have a number of things to do, so you put those things in a queue, and once in a while (like every nanosecond), the event loop picks an event from the queue, and runs it for a short while (maybe a millisecond or so), and either shoves it back in the queue if it hasn't completed, or waits until it yields control back to the event loop.
Now to answer some of your questions:
What does blocking / non-blocking mean here? I assume it means the
single thread that the event loop is on is blocked, so we cant process
other functions in parallel.
Blocking event loop
Blocking the event loop occurs when the event loop is running a task, and the task has either not finished or given back control to the event-loop, for a period of time longer than the event loop has scheduled it to run.
In the case of python's requests library, they make use of a synchronous http library, which doesn't respect the event loop; Therefore, running such a task in the loop will starve other tasks which are patiently waiting their turn to run, until the request is finished.
Why are most functions non-blocking in Javascript, but not in Python
(i.e we don't need specific libraries such as aiohttp).
JS
Everything in Javascript can block the event loop. The only way not to block the event loop is to make heavy use of callbacks via setTimeout. However, if care is not taken, even those callbacks can block the event loop if they run too long without yielding control back to the event loop via another setTimeout call.
(If you've never had to use setTimeout, but have used promises and async network requests in JS, then you are probably making use of a library that does. Most of the popular networking libraries used in browsers (ajax, axios, fetch, etc), are based on the popular XMLHttpRequest API, which provides async network IO.)
Python
In python, the story is slightly different: Before asyncio, there was no such thing as as "event loop". Everything must run to completion before python interpreter moves on to the next thing. This is part of what makes python very easy to learn (and dare I say, to create...). The reason for this, comes in the form of the python GIL, which in simple terms enforces a single order of execution for any python program. I encourage you to click that link, and read why the GIL exists.
And what about languages like Go with their goroutines?
Note: I am not a go programmer, but I read something
How is Go different?
The only difference between the way go handles goroutines and how python asyncio/js do their event loops, is that go makes more use of os threads to ensure that threads are scheduled fairly and make full use of the machine they run in.
While js callbacks/asyncio tasks will often run in the same thread as the event loop, goroutines are able to run in seperate OS threads and over multiple cores, thus giving them higher availability and higher parallelism. (In that case, we could almost consider goroutines to be closer to OS threads in terms of how much time they actually get to run, as compared to green threads which are bound by the amount of time the event loop's thread runs.)

setTimeout to achieve asynchronicity in Node

What is the point of doing setTimeout(fx, 0) in node?
This is not asynchronous or even non-blocking, as the async function is really the setTimeout, not your fx, and after setTimeout has run asynchronously, you will end up running fx which will block your code anyway.
Doing the setTimeout with 0 to call a function fx will just wait until the stack is empty to run fx, but then while fx is running you won't be able to accept any requests, right?
So is setTimeout(fx, 0) just a way of telling node 'hey, run this whenever you can'? Is there any way to trully run async functions in Node?

If your question is:
Can node run functions in parallel at the same time?
Then the answer is yes, but you have to use a web worker.
The paradigm of asynchronosity in node is different from traditional definitions. The expectation is that you don't run too many ultra-long running functions in node. This way, effective asynchronosity is achieved.
Node is good for some things, not for others, just like any environment.
For a more detailed answer, refer here
As for setTimeout(...,0) calls; sometimes giving a break during a time consuming task to allow calls in the queue have their share of processing can be required. Dividing tasks in different ways can save you from these; but still, this is not really a hack, it is just the way event queues work. Also, using process.nextTick for this aim is much better since when you use setTimeout, calculation and checks of the time passed will be necessary while process.nextTick is simply what we really want: "Hey task, go back to end of the queue, you have used your share!"

If I understand your question correctly the answer would be the following:
As JavaScript is a single threaded language it is still able to deal with two things separately.
Using setTimeout(fx, 0) allows you to push the function or operation within the setTimeout Function in a "waiting qeue". As soon as the Stack of operations is completed the function gets put onto the execution stack and gets executed.
More detailed information about that can be found in this video

Understanding event loop with twisted and node

I am trying to choose a platform to code my network application on, it will be a small realtime online game server. I am not very familiar with the async theory though I know how to write a little asynchronous code.
I both know javascript and python, on the same level.
So I was reading on twisted here and he says:
During a callback, the Twisted loop is effectively “blocked” on our
code. So we should make sure our callback code doesn’t waste any time.
In particular, we should avoid making blocking I/O calls in our
callbacks. Otherwise, we would be defeating the whole point of using
the reactor pattern in the first place. Twisted will not take any
special precautions to prevent our code from blocking, we just have to
make sure not to do it. As we will eventually see, for the common case
of network I/O we don’t have to worry about it as we let Twisted do
the asynchronous communication for us.
I wanted to see how this is different to how the event loop on node.js is done. I believe node.js implements the event loop and it never blocks, or am I missing something?
I write somewhat blocking codes on my callbacks with node.js does this mean I'm making a mistake?
Why is twisted called async and event driven when it still blocks?
Cheers,
Maj

Twisted, node.js, and every other asynchronous framework behave the exact same way here: If you writing blocking code in your callbacks, the entire event loop is blocked until your callback is done.
Asynchronous frameworks are really great for doing I/O-bound work; the event loop never gets blocked waiting for I/O, because it can all be done in a non-blocking way. When there is data ready for reading, the event loop fires off your callback, the callback handles the data, and then the event loop takes control again. When you hear these frameworks being called "async" and "event-driven", it's referring to this non-blocking I/O + event loop model.
However, when you actually need to do some kind of processing with the data being sent/received, you need to be careful. Event loops are single-threaded; only one CPU-based operation can happen at a time. That means if you do some expensive calculation that takes 10 seconds in a callback, your event loop is blocked for 10 seconds. There's no extra magic in node.js that avoids this.
If you want to be able to do CPU-based operations without blocking your event loop, node.js (and twisted) have mechanisms for sending the CPU-bound work to a sub-process, and then fetching the results when the sub-process is complete. The node.js About page actually mentions this:
But what about multiple-processor concurrency? Aren't threads
necessary to scale programs to multi-core computers? You can start new
processes via child_process.fork() these other processes will be
scheduled in parallel. For load balancing incoming connections across
multiple processes use the cluster module.

Javascript callback function on a separate thread

Javascript is single threaded. So does the callback function and it's containing function execute on the same thread as the main loop/event loop?
database.query("SELECT * FROM hugetable", function(rows) { // anonymous callback function
var result = rows;
console.log(result.length);
});
console.log("I am going without waiting...");
If query() method and its callback function executes on the same thread as the event loop does then the blocking will occur. If not why Javascript is called single-threaded?
Can anyone help verify that javascript(browser/node.js) is using multiple threads behind the scene in order to achieve non-blocking?
Friends,
I saw your comments and answers. Sorry I am very new to Javascript. I am confused in that single thread async call won't block. If there are 100 users request data from hugeTable which may take one minute each concurrently and the event loop dispatch these tasks in to a queue and execute them in turn how can the query() method execution not blocking the event loop since they are all on one single thread?
Brad answered this part.

Node.js native libraries (not the JavaScript portions) use separate threads all the time, but all of the data for your code gets shuffled back to a single JavaScript execution thread.
It's impossible to tell you if other threads in the background are working on this query, since you didn't specify what DB library you're using. However, that doesn't matter as much as you think.
Let's suppose you were to create a thread for handling your database connection. You fire off a query, and that thread takes care of getting the query to the database server. Then what? That thread sits around doing absolutely nothing until there's data to come back. You've effectively wasted resources keeping a thread around that doesn't do a whole lot. Node.js doesn't work this way. You have one thread for JavaScript execution.
If you are sending or receiving data (which is mostly what your DB connector is going to do), then this is handled out of a background thread pool for you automatically. It's also possible whatever DB connector you're using has a native extension that can do whatever it wants with threads.
See my post here for a more full explanation: https://stackoverflow.com/a/19324665/362536

Javascript is single threaded. So does the callback function and it's containing function execute on the same thread as the main loop/event loop?
Yes, you kind of answered your own question.
You are correct, JavaScript is single threaded. There is no other thread for a callback to execute on.
That said, external libraries written in C or C++ are free to spawn threads all they want.

Good question, javaScript is single-threaded yet asynchronous, that means for each asynchronous call it will perform a small pause on the main thread to execute the callback, at least that's for browsers and even there you will have web-workers that will spawn a new thread per worker.

What you're doing in your code is deferring the evaluation of the query (execution of the callback) until after the query has run and rows have been retrieved.
In modern browsers you can create two threads if desired using webworkers.
Node.js is a seperate story - you can create child processes which will run on a seperate thread when desired. See this post for further information.

Method to get the running thread id in javascript/jquery

I am new to javascript/jquery.
I have a simple question one of java script function is running and wanted to see the thread id for that thread.
In java we do like
Thread.getID();//in java
which will print the thread id of running thread.
In the similar way what is the function we use to get the running thread id in javscript.
Actually what i want is..
In my JavaScript, I have a listener which is listening to the channel. When ever there is a message in the channel, the callback method is called and processes the data. So here I am trying to see how it works in that way.. Let's say there are 10 messages in the channel and for each message the callback is called.
Let's say the callback method is running for a message "a" and while processing the data for the message "a", it got another message "b". Will the callback method for "b" be called once the processing for message "a" is complete?
I wanted to check this by printing the thread number in the callback function which tells whether it is running sequentially (one thread) or multiple threads. That is why I was trying to print the thread id. Thanks for your responses.
Thanks,
Swati

JavaScript is single threaded. So this wouldn't apply to JavaScript.
However, it is possible to spawn multiple threads through a very limited Worker interface introduced in HTML5 and is already available on some browsers. From an MDC article,
The Worker interface spawns real OS-level threads, and concurrency can cause interesting effects in your code if you aren't careful. However, in the case of web workers, the carefully controlled communication points with other threads means that it's actually very hard to cause concurrency problems. There's no access to non-thread safe components or the DOM and you have to pass specific data in and out of a thread through serialized objects. So you have to work really hard to cause problems in your code.
What do you need this for?

For most things in JavaScript there's one thread, so there's no method for this, since it'd invariable by "1" where you could access such information. There are more threads in the background for events and queuing (handled by the browser), but as far as your code's concerned, there's a main thread.
Java != JavaScript, they only share 4 letters :)

Aside from the name, Javascript is totally unrelated to Java. Javascript does not have threads that you can access.

In javascript the scripts run in a browser thread, and your code have no access to that info, actually your code have no idea whatsoever how it's being run. So NO! there's no such thing in javascript.