Programação assíncrona e multi-tarefa em MQL - página 16

 
Roman:

Eu já lhe escrevi, você está tentando construir um NS, você não precisa de assíncronia neste caso?
Mas você está construindo NS em funções simples de ativação, portanto, não encontrou falta de concorrência.
Mas quando você começar a construir modelos globais de NS, então você entenderá a beleza da assincronia.

mau exemplo - não é necessário!

@Roffild já escreveu no tópico"No mundo de hoje, um programador deve conhecer vários idiomas para poder escolher a ferramenta certa para uma tarefa específica". "

isto é verdade!

Na MQL não há escolha de pacotes para MQL - apenas AlgLib - quero considerar um exemplo, encontrado em Habra, eu pego e conecto C# ou Python à MQL - é isso, eu faço o que quero fazer, não portando código para MQL

Hoje em dia as linguagens de programação são interessantes não por suas características, mas por estruturas prontas! - Se na MQL houver novos pacotes MQL, então haverá outras tarefas e problemas!

ZS: mais uma vez, em meus dedos, você está se agarrando "à idéia de fx" que surgiu das linguagens multi-plataforma Python e Java, o sacrifício pela portabilidade e flexibilidade da linguagem foi a perda de desempenho, agora essas linguagens foram crescendo demais com diferentes maneiras de aumentar o desempenho, mas em linguagens tipo C os desenvolvedores sempre alcançam o máximo desempenho e não há necessidade (na maioria dos casos) de dividir a tarefa em threads separados (tarefas cliente - as tarefas do servidor não contam, aí o problema está na velocidade de troca de dados e esta é outra especificidade)

 
Igor Makanu:

mau exemplo - não é necessário!

@Roffild já escreveu no tópico"No mundo de hoje, um programador deve conhecer vários idiomas para poder escolher a ferramenta certa para uma tarefa específica". "

isto é verdade!

Na MQL não há escolha de pacotes para MQL - somente AlgLib - quero considerar um exemplo, encontrado em Habra, eu pego e conecto C# ou Python à MQL - isso é tudo, eu faço o que quero fazer, não portando código para MQL

Hoje em dia as linguagens de programação são interessantes não por suas características, mas por estruturas prontas! - Se na MQL houver novos pacotes MQL, então haverá outras tarefas e problemas!

ZS: mais uma vez em seus dedos, você está se agarrando "à idéia de fx" que surgiu das linguagens multi-plataforma Python e Java, o sacrifício pela portabilidade e flexibilidade da linguagem foi a perda de desempenho, agora essas linguagens se tornaram cercadas por várias formas de aumentar o desempenho, mas em linguagens tipo C os desenvolvedores sempre alcançam o máximo desempenho e não há necessidade (na maioria dos casos) de dividir a tarefa em threads separados (as tarefas cliente - tarefas do servidor não contam, aí o problema é a velocidade de troca de dados e esta é outra especificidade)

Você ignora constantemente as seguintes coisas:

1. A distribuição de programas que utilizam conexões externas não pode ser feita através do Mercado.

2. Programas que utilizam conexões externas exigem que o usuário seja um "professor" para conectar tudo corretamente. As instruções para o uso de tal programa são uma bagunça.

3. Os programas que utilizam conexões externas são adequados apenas para uso pessoal, o que limita muito o sentido de sua criação.

4. Os programas para uso pessoal são de qualidade inferior aos programas para venda, porque você pode fazer qualquer coisa por si mesmo... e você NÃO PODE ser o mesmo especialista em vários idiomas ao mesmo tempo. Alguns idiomas você conhecerá da quinta à décima língua e isso afetará a qualidade do produto.

5. Há muitas tarefas que requerem assíncrono e multi-tarefas. Os programas MQL ainda não alcançaram essas tarefas, mas isso não significa que eles não devam lutar por elas.

 
Roman:

...
O que alcança a assincronia em um único fluxo.

Não, bem, assíncronia sem multithreading é realmente algum tipo de bobagem, você precisa de pelo menos um fio adicional. Acho que seu EventLoop pode ser feito através de indicadores carregáveis. Comunicação entre indicadores especializados via soquetes, por exemplo. Uma tarefa foi criada, o indicador foi ligado, a tarefa foi enviada, o indicador informou a execução, solicitamos o status da tarefa ao Consultor Especialista, apagamos o indicador. Por meio de muletas, mas multi-tarefas.

 
Roman:

Sim, esse artigo é muito bom, para uma única solução, para pensar sobre isso, talvez você possa espremer algo mais desta abordagem.
Decidi sobre a direção do meu problema, graças ao Andrey pela dica.

O fato de você ter lido um artigo é bom.

Romano:

Não são os fios, ou seja, as chamadas sem bloqueio através de funções de colback, controladas pelo EventLoop.
Isto atinge a assincronia em um só fio.

Como você conseguiu não encontrá-lo na documentação?

Por que você não o lê?

 
Реter Konow:

Você ignora constantemente as seguintes coisas:

Você e eu temos tarefas diferentes, você não leva em conta que existem 2 grandes passos na escrita do software: o desenvolvimento e a implementação do software em si.

O desenvolvimento de software requer soluções prontas - leva tempo; se durante o desenvolvimento se verificar que o software não executará suas tarefas como planejado, ele vai para o lixo. E a implementação em si é um trabalho mecânico para as capacidades de uma determinada plataforma.


ReTeg Konow:

5. Há muitas tarefas que requerem assíncronia e multithreading. Os programas MQL ainda não atingiram essas tarefas, mas isso não significa que eles não devam lutar por elas.

Ok, agora vamos com você:

Responder à pergunta: por que oterminal comercial precisa disso?

 
Koldun Zloy:

O fato de você ter lido um artigo é bom.

Como você conseguiu não encontrá-lo na documentação?

Por que você não o lê?

Imagine não encontrá-lo.
A busca de callback e eventloop não encontra nada parecido na documentação.
Se você não se importa, me dê um link sem nenhum sarcasmo.

 
Igor Makanu:

Você e eu temos tarefas diferentes; você não leva em conta que existem duas grandes etapas na escrita do software: o desenvolvimento e a implementação do software.

O desenvolvimento de software requer soluções prontas - isso leva tempo; se durante o desenvolvimento se verificar que o software não executará suas tarefas como planejado, ele vai para o lixo. E a implementação em si é um trabalho mecânico para as capacidades de uma determinada plataforma.


OK, agora vamos com você:

2) Responda à pergunta, por que oterminal comercial precisa disso?

1. Tudo o que eu faço é desenvolvimento. Dificilmente 6 anos de desenvolvimento contínuo eu não entendo o que é. )) Acho que soluções externas prontas, arrancadas do contexto de outros programas ou abstraídas de alguns outros programas, se integram mal na estrutura de um código altamente especializado e podem ficar muito confusas. A mão-de-obra empregada neste caso é maior do que no desenvolvimento de sua própria solução e a qualidade final do código é menor. Sem mencionar o potencial de desenvolvimento. Estas são as realidades do desenvolvimento. Mas, isto é irrelevante para nossa pergunta. Na verdade, o que isso tem a ver com isso?

2. Você está fazendo a pergunta errada. A questão principal é "Por que o usuário final precisa disso". Porque o usuário está sempre com falta das características oferecidas. Portanto, eles devem ser adicionados para que não percam o interesse. Se ficarmos sem possibilidades e não pudermos acrescentar novas devido a limitações técnicas, o usuário desistirá. Oportunidades são necessárias para manter os usuários no terminal e a distribuição de software é necessária para este fim. Portanto, os programas que não podem ser distribuídos são inúteis para a comunidade, não importando quais idiomas usem.


Na verdade, você olha apenas para suas próprias necessidades e não leva em conta as necessidades de outros usuários. Você não faz e não quer fazer negócios nesta comunidade, e você apenas transmite a motivação para ganhar dinheiro no mercado. E você pode ganhar dinheiro no mercado sem nenhum software.

 
Igor Makanu:

mau exemplo - não é necessário!

@Roffild já escreveu no tópico"No mundo de hoje, um programador deve conhecer vários idiomas para escolher a ferramenta certa para uma determinada tarefa. "

isto é verdade!

Na MQL não há escolha de pacotes para MQL - apenas AlgLib - eu quero considerar um exemplo, encontrado em Habra, eu pego e conecto C# ou Python à MQL - é tudo, eu faço o que eu quero fazer, não portando código para MQL

Hoje em dia as linguagens de programação são interessantes não por suas características, mas por estruturas prontas! - Se na MQL houver novos pacotes MQL, então haverá outras tarefas e problemas!

ZS: mais uma vez em seus dedos, você está agarrado à "idéia fixa" que surgiu das linguagens multi-plataforma Python e Java, o sacrifício pela portabilidade e flexibilidade da linguagem foi a perda de desempenho, agora essas linguagens se tornaram cercadas por diferentes maneiras de aumentar o desempenho, mas em linguagens em C os desenvolvedores sempre alcançam o máximo desempenho e não há necessidade (na maioria dos casos) de dividir a tarefa em threads separados (tarefas cliente - tarefas do servidor não estão incluídas, aí o problema é a velocidade de troca de dados e esta é outra especificidade)

Igor, às vezes você se contradiz.
Da última vez que você escreveu que a velocidade de cálculo do mql é comparável à velocidade C++
OK, isto é de fato verdade e muitas pessoas sabem disso.
Mas então você dá um exemplo de conexão de estruturas de terceiros aos cálculos de porta, como você coloca em idiomas atrasados.
E você defende a conectividade de pacotes de terceiros. Então você está sacrificando velocidade por uma estrutura pronta para uso?
E assim, como Peter escreveu, você perde completamente a portabilidade do seu programa.
Não é uma boa solução. Para uso pessoal, sim, mas não para uso em massa.

 
Roman:

Imagine não encontrá-lo.
A busca de callback e eventloop não encontra nada parecido na documentação.
Se você não se importa, me dê um link sem sarcasmo desnecessário.

Não é preciso fazer uma busca, é preciso ler tudo. Tenho certeza de que há muitas surpresas aí para você.

Não haverá nenhum link.

Eu já ajudei pessoas aqui mais de uma vez que pelo menos tentaram fazer algo por si mesmas.

E o que você tem feito?

Você só fica sentado aí e olha sua boca no fórum?

Bem, estou lhe ajudando com isso.


 
Somente os fornecedores do mercado podem precisar de fluxos na MKL. Para todos os outros, já existem correntes. Precisa de algum processamento complexo? - Passe os eventos para uma DLL, crie e solte um fluxo e libere o fluxo terminal, e você será capaz de processá-los para sempre).
É preciso dizer que a maioria não vai lidar com os fios, e uma centena ou duas de todos os usuários da ICL vão precisar dele. A MKL se daria ao trabalho de uma centena de programadores que querem negociar no mercado?
Razão: