★ wanayoo — archive 1999 https://developer.mozilla.org/pt-BR/docs/Web/JavaScript/EventLoopNouvelle recherche | Portail wanayoo
mozilla
Os seus resultados da pesquisa

    Concurrency model and Event Loop

    Esta tradução está incompleta. Ajude atraduzir este artigo.

    JavaScript possui um modelo de concorrência baseado em "event loop". Este modelo é um pouco diferente de outras linguagens como C ou Java.

    Conceitos de runtime(tempo de execução)

    Os próximos tópicos irão explicar teoricamente o modelo. Engines modernas de javascript implementam e otimizam fortemente as semânticas descrita.

    Apresentação visual

    Stack, heap, queue

    Pilha

    Chamadas de funções criam uma pilha de quadros.

    function f(b){
      var a = 12;
      return a+b+35;
    }
    
    function g(x){
      var m = 4;
      return f(m*x);
    }
    
    g(21);
    

    Quando chamamos g, o primeiro quadro é criado contendo o argumentos e as variável locais de g. Quando g chama f, o segundo quadro é criado e é colocado no topo da pilha contendo o argumento e a variável local de f. Quando f retorna, o quadro do topo é removido da pilha (deixando apenas o quadro da chamada de g), quando g retorna a pilha fica vazia.

    Heap

    Objetos são alocados na heap o qual é alocado apenas o nome para denotar uma grande região não estruturada na memória.

    Fila

    O runtime do JavaScript contem uma fila de mensagem, o qual é uma lista de mensagens que deve ser processada. Para cada mensagem é associada uma função. Quando a pilha esta vazia, a mensagem é removida da fila e é processada. O processamento consiste em chamar a função associada (assim criando um quadro inicial na pilha). O processamento das mensagens termina quando a pilha se torna vazia de novo.

    Event loop

    O "event loop" tem esse nome porcausa da forma que ele é normalmente implementado, normalmente é semelhante a:

    while(queue.waitForMessage()){
      queue.processNextMessage();
    }

    queue.waitForMessage espera sincronicamente pela mensagem chegar.

    "Run-to-completion"

    Cada mensagem é processada completamente antes de outra mensagem ser processada. Isto oferece um bom raciocínio sobre o seu programa, incluindo o fato de que independente de quando uma função é executada, ela não pode ser interrompida e irá executar completamente antes que outro código execute (e pode modificar dados de funções manipuladas por esta). Desta forma difere do C, por exemplo, onde se a função estiver sendo executada em uma
    thread, ela pode ser interrompida a qualquer momento para executar um outro código em outra thread.

    A downside of this model is that if a message takes too long to complete, the web application is unable to process user interactions like click or scroll. The browser mitigates this with the "a script is taking too long to run" dialog. A good practice to follow is to make message processing short and if possible cut down one message into several messages.

    Adicionando mensagens

    Em navegadores, mensagens são adicionadas a qualquer momento que um evento é disparado se este possuir um "listener". Caso não possua, o evento será perdido. Então clicar em um elemento que possui um evento de clique irá adicionar uma mensagem, igualmente a qualquer outro evento.

    Chamar setTimeout irá adicionar uma mensagem a fila depois de passar o tempo como segundo argumento nos parametros. Se não existir outra mensagem na fila, 
    a mensagem será processada no mesmo momento; no entanto; se existir mensagens, a instrução setTimeout terá que esperar até que as outras mensagens sejam processadas. 
    Por este motivo o segundo argumento garante o tempo minimo e não o tempo exato.

    Several Runtime communicating together

    A web worker or a cross-origin iframe has its own stack, heap, and message queue. Two distinct runtimes can only communicate through sending messages via the postMessage method. This method adds a message to the other runtime if the latter listens to message events.

    Never blocking

    A very interesting property of the event loop model is that JavaScript, unlike a lot of other languages, never blocks. Handling I/O is typically performed via events and callbacks, so when the application is waiting for an IndexedDB query to return or an XHR request to return, it can still process other things like user input.

    Legacy exceptions exist like alert or synchronous XHR, but it is considered as a good practice to avoid them. Beware, exceptions to the exception do exist (but are usually implementation bugs rather than anything else).

    Etiquetas do documento e colaboradores

    Contribuíram para esta página: Felipe_Baravieira
    Última atualização por: Felipe_Baravieira,
    Esconder painel