Asynchronous and multi-threaded programming in MQL - page 8

 
Dmitry Fedoseev:

It seems that the special difference between asynchrony and multithreading comes from the same area as the pointer/reference difference issue which plagues some people.

Asynchrony is implemented through a separate thread and it is not so important whether this process is provided by processor or any other device. Creation of a process implies its asynchrony because it exists in parallel.

Asynchrony is implemented in the same program execution thread, through EventLoop, but how EventLoop is implemented is the developers' prerogative, how to implement it.
The same standard handlers in mql, for example OnTimer works in its own loop, and this is a kind of EventLoop,
If you want to create a separate handler for asynchronous methods, all tasks will be perfectly executed in an asynchronous loop.

 
Roman:

The asynchrony is implemented in the same program execution thread, through EventLoop, but how EventLoop is implemented, is the prerogative of developers, how to implement it.
The same standard handlers in mql, for example OnTimer works in its own loop, and this is a kind of EventLoop,
If you want to create a separate handler for asynchronous methods, all tasks will be perfectly executed in an asynchronous loop.

Excuse me, where is asynchrony implemented via EventLoop?

You can do something like EventLoop yourself now, terminal developers are not needed here at all.

 
Dmitry Fedoseev:

Excuse me, where is asynchrony implemented via EventLoop?

You can do something like EventLoop yourself now, the terminal developers are not needed here at all.

EventLoop is implemented in asyncio, and as I think the same principle is used in other asynchronous libraries.
Even WinAPI, as I understand it, uses the event principle for asynchrony.
We cannot implement full-fledged asynchronous mode using standard tools at present,
The reason is that the OnTimer handler, for example, does not control task execution and instead executes the loop sequentially.
That is, the handler lacks the mechanism of asynchronous task execution.

 

Everyone google the concept of deadlock!

In MQL5 adding threads will break the testing system and the whole agent cloud will crash.

A workaround to this limitation is possible with DLLs. If you do not want to learn C#, C++, C, Python - that's your problem. In today's world, a programmer must know several languages to correctly select a tool for a particular task.

Those who know 1C are not considered programmers. The same is true for MQL5.

 
Roffild:

Everyone google the concept of deadlock!

In MQL5 adding threads will break the testing system and the whole agent cloud will crash.

A workaround to this limitation is possible with DLLs. If you do not want to learn C#, C++, C, Python - that's your problem. In today's world, a programmer must know several languages to correctly select a tool for a particular task.

Those who know 1C are not considered programmers. The same is true for MQL5.

If multi-threaded MQL program breaks the testing system, then what difference does it make, whether it's attached through a DLL or a regular one? In any case, you'll have to choose between testing and multi-threading. But it's better to choose within MQL, because the integrity is a plus for the program.
 
Roffild:

Everyone google the concept of deadlock!

In MQL5 adding threads will break the testing system and the whole agent cloud will crash.

A workaround to this limitation is possible with DLLs. If you do not want to learn C#, C++, C, Python - that's your problem. In today's world, a programmer must know several languages to correctly select a tool for a particular task.

Those who know 1C are not considered programmers. The same is true for MQL5.

When testing, all tasks can be solved one by one and the results can be returned at certain moments (you can wait in the tester). Not only you can, but you must, so that it corresponds to reality.

I wonder what 1C programmers think about it? Are they interested in someone else's opinion?

 
Реter Konow:
If multi-threaded MQL program breaks the testing system, then what difference does it make, whether it's attached through a DLL or a regular one? In any case, you'll have to choose between testing and multi-threading. But it's better to choose within MQL, because the integrity is a plus for the program.
Generally, multi-threading is required in normal mode. Testing always works with one small program module - a strategy, and all other capabilities of the program have a rest. Visualization and so on. So, during testing only that thread where the strategy module is located will be running. In the tester, some regular functions and events are disabled, so let the threads be disabled as well.
 
Реter Konow:
If multi-threaded MQL program breaks the testing system, what difference does it make how it's attached, via a DLL or a regular one? In any case, you'll have to choose between testing and multi-threading. But it's better to choose within MQL, because the integrity is a plus for the program.

There is a difference. DLLs are not allowed in the cloud. And the DLLs themselves are disabled from the start. By enabling permission for DLLs, you are abdicating the responsibility of safe code execution.

 
Roman:

EventLoop is implemented in asyncio, and I believe the same principle is used in other asynchronous libraries.
...

Other asynchronous libraries do not use this principle.

 
Dmitry Fedoseev:

Other asynchronous libraries do not use this principle.

This was just a guess, I have not checked where else it is used.
Googled what languages use EventLoop, it is Py, JS, Qt, probably some more.
The point is not where it is applied but in the technology itself without using threads.
So why not borrow the technology and implement in mql your EventLoop?