Fluxo de eventos. Como controlar e tornar o evento inactivo ? (+ resolvido) - página 2
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Yedelkin:
Consequentemente, ainda não está claro com que frequência os eventos dos utilizadores devem ser enviados para que não transbordem a fila de eventos terminais...
Não consigo encontrar uma resposta para a pergunta: como é que uma fila de eventos transborda afecta o tamanho da RAM? Se a fila de eventos estiver cheia, para onde vão os eventos que transbordaram a fila? Será que parte da RAM, reservada para aqueles eventos que aconteceram "fora da história", é libertada?
Talvez as minhas perguntas não sejam terminologicamente correctas, mas (espero) captam a essência do problema.
A fila é dinâmica e cresce por necessidade.
Mas a um certo limite, novos eventos são descartados, pois é evidente que não vale a pena carregar mais a fila.
Posso dizer desde já que não leu as minhas mensagens.
Porque não o "leu"? Você resolveu o seu problema, eu estou a tentar resolver o meu, de um tipo diferente. Quando li a discussão, não encontrei uma resposta às minhas perguntas.
Não respondeu à minha pergunta principal. :/ Isso é exactamente o "ver de relance" :)
A fila é dinâmica e cresce por necessidade.
Mas a um certo limite, novos eventos são descartados, porque é evidente que não vale a pena carregar mais a fila.
OK, a fila é "dinâmica". Aumenta para um limite "certo". Mas porque é que ninguém pode dar uma resposta a uma pergunta aparentemente simples: como é que o excesso de fila de eventos afecta o tamanho da memória?
Perguntas de seguimento: Quanto RAM é necessário para "manter" uma fila de eventos sobrecarregada? Se "a um certo limite, novos eventos são descartados", a RAM é previamente alocada para estes eventos descartados libertada?
Objectivo das perguntas: compreender como o fluxo de eventos do utilizador pode aumentar (aumenta) a quantidade de RAM consumida pelo terminal.
Se a fila de eventos estiver cheia, para onde vão os eventos que transbordaram a fila? Parte da RAM está reservada para os eventos que estão "fora da história" libertados?
Talvez as minhas perguntas não sejam terminologicamente correctas, mas (espero) elas transmitem a essência do problema.
A secção diz Execução de Programas que novos eventos são descartados quando a fila transborda:
O terminal do cliente envia os eventos ocorridos para os gráficos abertos apropriados. Os eventos também podem ser gerados por gráficos (eventos de gráficos) ou programas mql5 (eventos personalizados). A geração de eventos de criação e eliminação de objectos gráficos num gráfico pode ser activada ou desactivada através da definição das propriedades CHART_EVENT_OBJECT_CREATE e CHART_EVENT_OBJECT_DELETE de um gráfico. Cada programa de mql5 e cada gráfico tem a sua própria fila de eventos, onde todos os novos eventos são armazenados.
O programa recebe eventos apenas do gráfico, no qual está a decorrer. Todos os eventos são processados um a um na ordem de recepção. Se já houver um evento NewTick na fila ou se este evento estiver no estado de processamento, um novo evento NewTick não é colocado na fila do programa mql5. Da mesma forma, se a fila do programa mql5 já contém o evento ChartEvent ou o evento está a ser processado, um novo evento deste tipo não é colocado na fila.
As filas de eventos têm um tamanho limitado, mas suficiente, por isso é pouco provável que a fila transborde para um programa correctamente escrito. Quando o transbordo da fila ocorre, novos eventos são descartados sem serem enfileirados.
É altamente desencorajado o uso de loops infinitos para processar eventos. A única excepção a esta regra são os guiões que tratam de um único evento Start.
As bibliotecas não tratam de quaisquer eventos.
Porque não o "leu"? Você resolveu o seu problema, eu estou a tentar resolver o meu, de um tipo diferente. Quando li a discussão, não encontrei uma resposta às minhas perguntas.
Não respondeu à minha pergunta principal. :/ Eu poderia definitivamente "ver imediatamente" :)
A sua pergunta "qual é a frequência aproximada em que os eventos dos utilizadores devem ser enviados, para que não transbordem a fila".
A minha resposta na primeira página é "com a frequência das chamadas OnChartEvent".
Ou seja, um evento é um OnChartEvent. Não deve haver mais do que dois eventos no meio.
Isso é tudo matemática.
Mais uma vez, leia a primeira página. Mostrei como evitar a acumulação de eventos do utilizador quando o evento terminal é processado em vez do evento do utilizador. É tão simples quanto isso.
Objectivo das perguntas: compreender como um fio de eventos do utilizador pode aumentar (aumentar) o tamanho da RAM consumida pelo terminal.
Porquê? Pois bem, sim, é verdade. O preço da pergunta é de alguns megabytes.
Esse não é o problema, ou não é realmente o problema.
A secção diz Execução do Programa, que
1. a secção do Manual sofreu alterações significativas.
1.1 Por exemplo, costumava ser:"O terminal do cliente coloca todos os eventos que ocorrem numa fila comum. Assim, os eventos são processados um após o outro por ordem de chegada. A excepção é o evento NewTick. Se já houver um evento deste tipo na fila ou se este evento estiver a ser processado, um novo evento NewTick não é colocado na fila".
Agora:"O programa recebe eventos apenas do gráfico em que está a decorrer. Todos os eventos são processados um após o outro na ordem em que são recebidos. Se já houver um evento NewTick na fila ou se este evento estiver no estado de processamento, um novo evento NewTick não é colocado na fila do programa mql5. Da mesma forma, se já existe um evento ChartEvent na fila de mql5-programa ou se tal evento está a ser processado, um novo evento deste tipo não é colocado na fila.
Como diz o ditado, "Ver a diferença". Deve, pelo menos, ser avisado. :/ Esta mudança muda fundamentalmente a forma como trabalhamos com eventos personalizados.
1.2. seguinte. O princípio do descarte de eventos é virado ao contrário. Costumava ser: "A fila do evento tem um tamanho limitado. Quando a fila fica cheia, os eventos antigos são apagados sem serem processados para dar lugar a novos eventos recebidos".
Agora: "Quando a fila está cheia, novos eventos são descartados sem serem enfileirados". Como se costuma dizer, obrigado: perdemos os eventos de utilizador mais relevantes.
2. A secção citada do Manual não responde às minhas perguntas básicas: Como é que o transbordo de filas de eventos afecta o tamanho da RAM? Quanta RAM é necessária para "manter" uma fila de eventos a transbordar? Se "a um certo limite, novos eventos são descartados", a RAM é previamente atribuída para os eventos descartados libertados?
TheXpert:
Objectivo das perguntas: compreender como um fluxo de eventos do utilizador pode aumentar (aumentar) o tamanho da RAM consumida pelo terminal.
Porquê? Pois bem, sim, é verdade. A questão vale vários megabytes.
2. A secção citada no Manual não responde às minhas principais perguntas: Como é que o transbordo de filas de eventos afecta o tamanho da RAM? Quanta RAM é necessária para "manter" uma fila de eventos a transbordar? Se "a um certo limite, novos eventos são descartados", a RAM é previamente atribuída para os eventos descartados libertados?
Se tais problemas surgirem, as coisas são muito más. Penso que uma fila de eventos a transbordar é o último lugar a procurar problemas de memória.
Se um evento é descartado, então não está a ser colocado na fila de espera. A memória não está a crescer.