What is the real advantage of using a Callback and what is thread/multithread?

Asked

Viewed 2,439 times

23

There is a lot of explanation of what callback is on the net and even a few scant examples, but nothing that explains in practice and in detail a really important use (I did not find).

I already understood a little of how to use and even did my version from an example I found on the net, however, it can be replicated without using callback and work the same or even better

I’m trying to introduce myself into the concepts and patterns of Node.js that are full of this: multithread, callback, asynchronmentalism etc, but while I don’t really understand what a callback is for or what a thread is I think I’ll never learn Node.js for real.

I would like simple examples and/or some classic and essential example in Node.js since it is my focus.

Note: I’ve only been studying programming for seven months and so far I’ve only touched the client side, my back-end journey is recent. This can be useful to forge the answer.

  • 7

    Why -2 in this question?

  • 3

    As in "no callback", both examples have "callback"? I’m not the one who said no, but I suppose that’s why. Note: Callback is something that is in the "soul" of Ecmascript codes, not working with Callback in it is the same as "limit" almost all its functionalities, in other words, it is not a matter of head start, is how the language works in most javascript codes. Note 2: Both of your examples use callback, you just couldn’t figure it out.

  • @Sergio is, I didn’t understand it either. Maybe they thought the title referred to two different subjects... in the end...

  • 2

    Maybe you’re ignoring my comment friend, but I’m just saying this: As far as you think you didn’t apply callback, you applied, you just didn’t notice. That inside the setTimeout in the two examples are "callbacks". So the first example has 2 callbacks, the second only one callback.

  • @Guilhermenascimento, I know I applied callback to setTimeout but the question is to present the "structure" made by me and not the setTimeout. I should have taken him away...

  • 1

    @ropbla9 That way you worked is useful when code works in an ASYNCHRONOUS way, thus avoiding engine freezing, almost everything in Ecmascript is preferable to work asynchronously, so one execution won’t have to wait for the other to respond and the two of you can work side by side. Note: In a code that does a great routine and takes some time, this can prevent other codes from having to wait for it to end (of course you have to know how to implement this).

  • @Guillhermenascimento, could you write me an answer?

  • 1

    This my answer maybe it’ll help you.

Show 3 more comments

3 answers

24


The largest Javascript process is consider a single event. If you perform a long operation within this event the process may lock for a few moments the browser (or other software that uses Ecmascript), then the process will stop processing other events until it completes its operation and will probably freeze the browser.

For example if you use XMLHttpRequest in this way:

var xhr = new XMLHttpRequest();
xhr.open('GET', 'url_arquivo_grande', false); //false = síncrono
xhr.send(null);
alert(xhr.responseText);
alert('Outra tarefa...');//Isto iria demorar de aparecer e provavelmente o navegador irá congelar

The main process of the browser will stay locked until the server has finished sending the response to the client and the client (client in the case of the browser) process this response.

Therefore in XMLHttpRequest we used to use AJAX (Asynchronous Javascript and XML) which would be the asynchronous way of it, which would be something like:

var xhr = new XMLHttpRequest();
xhr.open('GET', 'url_arquivo_grande', true); //true = assincrono
xhr.onreadystachange = function () { alert(xhr.responseText); };
xhr.send(null);
alert('Outra tarefa...');//Isto não espera o ajax

You don’t need to use callback for everything, but if your code has a great chance to block/freeze other operations it is essential that you use asynchronous methods, or even setTimeout.

Which really brings us to callback

If the code is delayed (even if it is not XMLHttpRequest), worth you resort to a setTimeout, from this moment you nay will be able to use the return ..., then it will be necessary to use the callback.

But it’s like I said, there’s no need to use callback at all, just where asynchronous events will be required.

Example of need 1:

In this example below we will try to use return, but when we use setTimeout, the return finish the process before the setTimeout, in other words the return will return 0, only after a millisecond the variable will be with the value 1, however return was sued before this:

function test() {
   var a = 0;
   setTimeout(function() {
      //Código demorado
      a = 1;
      //Código demorado
   }, 1);
   return a;
}
console.log(test());//Irá retornar 0

With callback it is possible to capture the response of an "asynchronous event":

function test(callback) {
   var a = 0;
   setTimeout(function() {
      //Código demorado
      a = 1;
      //Código demorado
      callback(a);
   }, 1);
}

test(function (response) {
    console.log(response);//Irá retornar "1"
});

Example of necessity 2:

In the following example I used XMLHttpRequest asynchronous because it prevents freezing, but I tried to capture responseText, but since the answer is not yet ready the result will be an "empty string", null or undefined.

function ajax() {
    var xhr = new XMLHttpRequest();
    xhr.open('GET', 'url_arquivo_grande', true);
    xhr.send(null);
    return xhr.responseText;
}
console.log(ajax());//Irá retornar null ou undefined

But if we use onreadystatechange, we can wait for the server response, but it will not be possible to use return, because it event is in another cycle/following or is it asynchronous, as in the example:

function ajax() {
    var data = null;
    var xhr = new XMLHttpRequest();
    xhr.open('GET', 'url_arquivo_grande', true);
    xhr.onreadystatechange = function() {
        if (xhr.readyState == 4) {
            if (xhr.status === 200) {
               data = xhr.responseText;
            }
        }
    };
    xhr.send(null);
    return data;
}
console.log(ajax());//Irá retornar null

So the solution is to use callback:

function ajax(callback) {
    var data = null;
    var xhr = new XMLHttpRequest();
    xhr.open('GET', 'url_arquivo_grande', true);
    xhr.onreadystatechange = function() {
        if (xhr.readyState == 4) {
            if (xhr.status === 200) {
               callback(xhr.responseText);
            }
        }
    };
    xhr.send(null);
}

test(function (response) {
    console.log(response);//Irá retornar "1"
});

Note, just because we have one setTimeout, does not mean that it will be warranty against "crashes", so it follows a list of technologies developed to make the user experience better:

Note that Node.js is an asynchronous "server", unlike Apache which is synchronous. The probability of asynchronous servers performing better is very high and for this reason it is so "rated".

Asynchronous to synchronous difference:

As explained earlier, the reason for using callback in particular is because of asynchronous events, but if it was not possible to understand what is ASYNCHRONOUS, see an example of the difference between "synchrony" and "asynchronous" and why we cannot use asynchronous with return:

síncrono vs assíncrono

The first (synchronous) drawing illustrates that a=1; is in line and return a; will only be executed after a=1;, the disadvantage and if a=1; is a time-consuming process, so this can slow down the main process, if it doesn’t slow down, then yes you can use synchronous.

The image illustrates that the a=1; is in an asynchronous event (can be ajax, setTimeout, or other types), see that a=1; was only delivered after the return a;, so this return runs first and does not bring the necessary response, in the example it will bring the value 0 instead of 1, then in this case it will be necessary the "callback".

  • why you can’t pick up the function’s Return if it’s in the callback of a setTimeout?

  • 2

    @ropbla9 I edited my answer.

  • 1

    Got it, thanks + 1 time

8

Javascript is single-thread

Both in the browser and outside it (nodejs), javascript runs within a single line of execution (or Thread, in English). Some languages allow you to create threads, but not javascript.

For example:

var a = 1;
for (var i=0; i<100000000; i++) { a++; }

If this code takes 10 seconds to execute, the execution of any other instruction in the system will be stopped for 10 seconds.

If in the browser this is not a good idea, on the server side (nodejs) it is even worse, because no other request will be met until the above looping is finished.

Callback to solve the problem

To solve the above problem, the use of callback functions was invented. It’s like this - I/O operations like file reading and writing, database access or server connections take a lot of running time, so not to lock the whole system in these situations, the solution found in javascript was the use of callback functions.

Callback functions are passed as parameter and calls when the operation ends. For example, in nodejs, to read a file you use the following instruction:

var fs = require('fs);
fs.readFile('c:\myfile.txt', function (err, data) {
  if (err) {
    console.log(err);
  }
  else {
    console.log(data);
  }
});

console.log('teste');

In the above example, the first line tries to read the file passed as parameter. Since file reading is a time-consuming process (in computational cycles), control is passed to the Node IO library (Unit 'Fs'), and execution continues to the next line, where the 'test' message is displayed on the console screen.

When the file is read or an error occurs (for example, file not found), the Fs.readFile function will call the callback function which will show the error message or the contents of the file.

I hope I’ve helped.

6

What’s the real advantage of using a Callback?

The advantage is to be able to define a parameter in a class that is actually a function. This exempts the programmer from a framework, for example, writing this function, leaving it to a programmer. The framework only calls the function defined by the programmer without necessarily verifying what this function does.

While advantageous for flexibility and freedom, and the possibility to extend the functionality of an object, the callbacks approach is somewhat permissive, and therefore dangerous, because it can make the programmer define a function that extrapolates aspects such as security and responsibility of information.

What is Thread/Multithread?

Thread (in Portuguese, running chain line) is a way for a process to divide itself into two or more tasks that can be performed competitively.

Multithread is the ability of a process to handle multiple lines of execution, functionality claimed by Node.js, although the Javascript programming language does not have this feature.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.