A assinatura do OnBookEvent às vezes cai - existe algo assim? - página 2

 
Stanislav Korotky:

"basta um especialista cancelar a inscrição para não receber o evento, e todos os outros especialistas deixarão de recebê-lo também"?

É um "não-cérebro".
 
Stanislav Korotky:

É apenas um palpite se vale ou não a pena - na analogia de continuar que "tudo o que é preciso é que uma EA se anule de receber um evento, e todas as outras EA deixarão de recebê-lo também"? Não creio que possa haver tal coisa, seria (ou é) um bicho.

Por um lado, é fácil de verificar. Eu mesmo o faria, mas só tenho uma conta FORTS e ela está fechada no fim de semana.

Mas se assim for, a situação se revela engraçada. Quando você habilitou o Expert Advisor e o indicador, as assinaturas foram acionadas. Quando você desabilita o Expert Advisor ou o indicador, você já escreveu que as assinaturas falharam. Isto sugere que a radiodifusão funciona na direção oposta. Agora imagine que algo mudou (por exemplo, a história mudou e o indicador foi recalculado). Mas sabemos que o OnInit e o OnDeinit podem ser chamados aleatoriamente. Algumas vezes é correto, outras vezes é o contrário. O que acontecerá se o gráfico chamar primeiro a nova versão do indicador, e depois desinstalar a antiga? A assinatura será cancelada. Isso é o que seria "cair calmamente". Eu recomendaria que você colocasse impressoras no OnInit e OnDeinit para verificar a fila e a mensagem no caso de as cotações de estoque pararem de chegar. Talvez o problema se esclareça.

 
Sergey Savinkin:

Antes de mais nada, é fácil de verificar. Eu mesmo o faria, mas só tenho uma conta na FORTS e ela está fechada no fim de semana.

Você não precisaCHARTEVENT_OBJECT_CREATE para verificar a pontuação de forma alguma.

 
https://yandex.ru/images/search?source=wiz&text=два%20выключателя%20на%20одну%20лампочку&img_url=https%3A%2F%2Frepair-need.ru%2Fuploads%2Fdico-kebfbf.jpg&pos=3&rpt=simage&lr=213
Яндекс.Картинки
  • yandex.ru
Результаты поиска по запросу "два выключателя на одну лампочку" в Яндекс.Картинках
 
A100:
É um "nobrainer".

Não entendo. Você sempre pode colocar um contador de links

 
TheXpert:

Não entendo. Você sempre pode colocar um contador de links

Não há contador. E se existisse, seria declarado explicitamente na documentação sobre sua existência e admissibilidade de chamada de par Add\Release apenas - caso contrário, o contador será quebrado e o significado de sua existência será perdido

E se você diz que precisa de um contador de referência... então você poderia ir mais longe e abolir totalmente a radiodifusão

 
A100:

Não há contador. E se houvesse, seria claramente declarado na documentação que existe e só é permitido acrescentar/liberar chamada emparelhada - caso contrário o contador será perdido e o significado de sua existência será perdido

e neste momento a função de liberação não tem sentido porque a lógica de que qualquer um pode cancelar a inscrição de seu evento é um disparate.

 

Há uma sugestão simples de simplesmente não utilizar a funçãoMarketBookRelease.

Em teoria, isto desperdiçaria alguns dos recursos do terminal e do servidor.

Mas na prática... Haverá alguma conseqüência real disso?

 
TheXpert:

Bem, agora não há sentido na função de liberação. porque a lógica de que qualquer um pode cancelar a inscrição de seu evento é uma lógica sem sentido.

Mesmo que haja um contador, qualquer um pode cancelar a assinatura ligando para orelease quantas vezes foremnecessárias - muito provavelmente o contador não seria capaz de detectar chamadas extras e o problema atual se transformaria em um problema com um contador com defeito de funcionamento. E se você pudesse usar um contador inteligente, você poderia acabar com a transmissão como tal.
 

É inútil explicar para os porcos-espinhos, então vou escrever para os outros ;-).

A noção de transmissão de eventos é uma coisa, mas os princípios de chamar em pares as funções de assinatura e cancelamento de assinatura de um evento é outra. Estas são técnicas semanticamente independentes que não precisam, e idealmente não devem, afetar umas às outras. Deixe o evento ser transmitido (isto provavelmente foi feito por razões de eficiência, mas é muito controverso e pode causar o problema atual se implementado incorretamente). Isto significa que basta uma assinatura, para que todos recebam o evento. Mas ao contrário - é preciso cancelar a inscrição e todos se ferram - já é uma espécie de "narrowcasting".

Sobre o balcão de assinantes na documentação não é mencionado, embora seja muito importante (e a frase sobre radiodifusão não é uma explicação para o motivo acima). A radiodifusão deveria durar idealmente até que o número de assinantes diminua para 0. Caso contrário, é óbvio que os programas MQL (incluindo os de diferentes desenvolvedores) teriam que se comunicar de alguma forma, de modo a não prejudicar seu trabalho, mas isso é um absurdo. Não conheço um único exemplo de software (no sentido amplo, não limitado a MT, Windows, etc.) onde a assinatura foi implementada desta forma.

Há esta passagem sobre o MarketBookRelease:

Обычно эта функция должна вызываться из функции OnDeinit() в том случае, если в функции OnInit() была вызвана соответствующая функция MarketBookAdd().

É, mais uma vez, ambíguo. Poderia ser interpretado como tendo controle sobre o número de assinaturas. Mas o software não permite interpretações privadas.

Resumindo, IMHO, a implementação é um rake (verificação e sobre-assinatura é necessária em nível de MQL), a documentação é obscura. A afirmação de que código malicioso ou completamente ruim pode matar as assinaturas dos outros, mesmo com um contador, não é realmente relevante. Todos esses scripts poderiam causar danos em um monte de outros lugares no terminal (por exemplo, apagar objetos de outras pessoas, matar paradas em posições de outras pessoas, etc., o que já aconteceu um milhão de vezes antes). Não faz sentido falar sobre tais manifestações piggyback - elas não podem ser impedidas por nada, exceto pela disciplina do usuário, a revisão do código de outros usuários (se houver algum) ou a verificação de uma demonstração. O problema agora é que o código devidamente escrito não pode funcionar corretamente agora.

Se fizéssemos este mecanismo corretamente, é claro - o padrão editor/assinante não foi abolido. Isso certamente não afetaria a eficiência.