MT5 and speed in action - page 73
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Please tell me an example where asynchronous events are required and this is not feasible right now by standard means.
The fxsaber beats getting a timely SymbolInfoTick(). Because of the blocking operation of the handlers, this is a problem. This is two.
Reading sockets from different handlers, that's a problem. This is three.
Looping loops in the handlers. This is four.
Long calculations. This is five.
Unable to receive handler events in a timely manner if another handler is busy. This is six.
A lot of restrictions occur due to the blocking model of handlers.
The list can go on and on, as long as you have enough imagination.
Not to mention chart events, graphical rendering events, etc.
Why? I understand how applications work in Win.
You better find out the history of Python, where and when did these well-named asynchronous crutches come from? - You understand that python architecture did not originally allow for these solutions?
I agree that thanks to these asynchronous things you can usePython for client-server solutions, maybe it's cool that the user's frontend can now use the resources of a multi-processor server,
but why would a user in a desktop application have a terminal in Win? - Well, if you get more threads, even if you can synchronize them with some await-functions, a common pool of messages/events will remain
Okay, I'm sick of arguing here in front of you all forum, clutter the threads with your fantasies, not my problem.
And you don't have to start with your fantasies. Nobody's asking you to. If you don't know what I'm talking about, it's better to keep quiet, you'll pass for literate.
It all started with mismatch of OnTick OnBook events, and Slava confirmed it. That's one.
The fxsaber beats getting a timely SymbolInfoTick(). Because of the blocking operation of the handlers, this is a problem. This is two.
Reading sockets from different handlers, that's a problem. This is three.
Looping loops in the handlers. This is four.
Long calculations. This is five.
Unable to receive handler events in a timely manner if another handler is busy. This is six.
A lot of restrictions occur due to the blocking model of handlers.
The list can go on and on, as far as one can imagine.
The solution is simple - move the handlers to separate Expert Advisors. Any event model can be implemented by standard means of MT5.
Another thing is that Windows is not a real-time system, but even if it were, the event must be processed faster than the intended one, but not instantly in any case. Therefore, developers are right (although it is not for me and not for you to judge whether they are right or not): you want to execute programs faster - buy processors and memory faster and with as many real cores as possible.
The solution is simple - move the handlers to separate Expert Advisors. Any event model can be implemented by MT5 standard means.
Another thing is that Windows is not a real-time system, but even if it were, the event must be processed faster than the intended one, but not instantly in any case.
So the developers are right: you want to execute programs faster - buy processors and memory faster and as many real cores as possible.
This is not a solution, but a crutch )) handlers scattered in separate programs. They teach you a bad thing here ))
Developers are wrong here, all serious projects are written asynchronously by normal programmers.
It is not hardware you need to raise, but the architecture of program execution.
Go and learn asynchronous programming, you're getting fed up.
Roman, boy. Calm down already.
Roman, boy. Calm down already.
Uncle Slava )) write all the handlers in a non-blocking event loop. You'll solve a lot of problems.
This is not a solution, but a crutch )) handlers scattered in separate programs. They teach you a bad thing here ))
Developers are wrong here, all serious projects are written asynchronously by normal programmers.
It is not the hardware that needs to be upgraded, but the architecture of program execution.
What is the problem? You write your own code and you're proven right.
I admire those dudes, they didn't tell you off, they tried to explain. In a very courteous manner. They don't need to prove anything to you - they're self-sufficient. Saber has been banned here more than anyone else. Dick has been banned too. Igor is the correctness itself, and he is constantly learning. But we have a very fruitful dialogue with them. Unlike you.
Uncle Slava )) write all the handlers in a non-blocking event loop. You'll solve a lot of problems.
The non-blocking one does not work. Purely for objective reasons
What's the problem? You wrote your own code - you proved your point.
I admire those dudes, they didn't send you away, they tried to explain. In a very courteous manner. They don't need to prove anything to you - they're self-sufficient. Saber has been banned here more than anyone else. Dick has been banned too. Igor is the correctness itself, and he is constantly learning. But we have a very fruitful dialogue with them. Unlike you.
If people here don't understand what they are writing about, I'm sorry, it's not my problem, it's the problem of those who don't smoke the topic of conversation.
The non-blocking one does not work. Purely for objective reasons.
Can you specify these objective reasons?