Asynchronous and multi-threaded programming in MQL - page 19
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
...
Once again, answer the question: why does the trading terminal need this?
...Does the terminal work in one thread? If it's in multiple threads, is that why it's needed?))
There's a lot of reasoning to be done.
Hmm, is that where you go, too? - You write a lot, but you do not read and do not want to develop? - You would not have had time at my link, not only to understand the article, but even read, here's the latest that I found, here's my code on the "3 screens Elder", wrote to someone, I have a code structure is always about that (provided that will not be further modifications that change the basic logic, there code ... better not to remember what can be done to initially linearstructured code (( ) )
below will be all the service functions, but the main code - the TC itself as much readable and most linear logic, I always wrote so, at university teachers only such sources accepted as handed in work, otherwise you will not pass ))))
what's the point? - I am trying to say once again: multi-threading should be used only if there is no other solution, no one from the adequate programmers will just go to work with asynchronous operations! - it hurts! ))))
an example will be from you: answer the question why a trading terminal needs it?
Yes, they are in the docks, but in reality they are not. As far as I understood.
I have tried it now. Everything is working.
Although they are of no practical use in MQL.
Answer the question why does the trading terminal need this?
...
An example would be from you: answer the question why does the trading terminal need it?
I have already answered you. You are ignoring.
1. I need multithreading because my programs are much more complex. I want to combine a lot of heavy functions in one program. Three-dimensional visualization, server communication, GUI, and various calculations. A single thread is not enough. So, I must either split the program into parts or use the native multithreading. If it's not available, then I'll split the program into parts.
2. the terminal is multi-threaded by itself. Ask its developers why it needs multithreading. Why I need multithreading - see point 1.
Igor Makanu
example from you: answer the question why the trading terminal needs it?
Well, the most obvious one is a separate interface thread, especially critical for guineas, although I do without it myself.
ZS: I do not advocate multithreading, if anything.
I have already replied to you. You are ignoring.
1. I need multithreading because my programs are much more complex. I want to combine a lot of very heavy functions in one program. Three-dimensional visualization, server communication, GUI, and various calculations. A single thread is not enough. So, I must either split the program into parts or use the native multithreading. If it's not there, then I'll split the program into parts.
2) The Terminal is multi-threaded in itself. Why it needs multi-threading - ask its developers. Why I need multi-threading - see point 1.
You also ignore what you are told, I've already written: flies separate - cutlets separate!
In your topic about your approach to graphical interfaces, you were told that your code is inefficient and you think that by throwing out functions into a separate thread you will increase performance? - It won't increase performance, but it will create the additional hassle of synchronizing everything now ))))
Remembering on 4pd in the threads about android - devices, the users are convinced of the effectiveness of the firmware version only by the amount of free memory, and quite the opposite - the more free memory, the cooler the firmware, but unfortunately there is no understanding that the OS must efficiently use all the resources - including memory, if there is much free memory, not necessarily the OS uses resources efficiently. So in your case, you can't get performance in one thread, so you need more threads! - Maybe it's not aboutthe capabilities of the language (platform, OS...) but about the developer? - Maybe he isn't efficient? ;) - I checked the GUIs from the article series and in KB last year, I didn't see any obvious lags, everything works at a good level. I looked at the source code of those codes, the interface element traversal schemes, the OOP approaches themselves - all very similar to the principles of graphics in Windows - why does it work for them and not for you? )))))) - Maybe the initial approach was not correct after all, oryour theoretical background is lame on both paws?
You also ignore what is written to you, I have already written: flies separate - cutlets separate! GUI and trading strategy should not be executed in one code!
In your topic about your approach to graphical interfaces, you were told that your code is inefficient and you think that by throwing out functions into a separate thread you will increase performance? - It won't increase performance, but it will create the additional hassle of synchronizing everything now ))))
Remembering on 4pd in the threads about android - devices, the users are convinced of the effectiveness of the firmware version only by the amount of free memory, and quite the opposite - the more free memory, the cooler the firmware, but unfortunately there is no understanding that the OS must efficiently use all the resources - including memory, if there is much free memory, not necessarily the OS uses resources efficiently. So in your case, you can't get performance in one thread, so you need more threads! - Maybe it's not about the capabilities of the language(platform, OS...) but about the developer? - Maybe he isn't efficient? ;) - I checked the GUIs from the article series and in KB last year, I didn't see any obvious lags, everything works at a good level. I looked at the source code of those codes, the interface element traversal schemes, the OOP approaches themselves - all very similar to the principles of graphics in Windows - why does it work for them and not for you? )))))) - maybe the initial approach wasn't right after all, or your theoretical background is lame on both paws?
What makes you think that something is inefficient or doesn't work for me? Go to my profile and see how things work. It is precisely because things are working and evolving that I assume the need for multithreading is imminent.
Well, the most obvious one is a separate interface thread, especially critical for guini, although I do without it myself.
ZS: I'm not advocating multithreading, if anything.
Well, you don't have products in the Marketplace. Then why make a GUI in MKL when it's easily made in C#, which now easily connects to MKL. And that GUI is already inherently running in its own thread.
Here is an example of writing linear asynchronous code in one thread.
Assuming that the EventLoop functionality is implemented in mql and implemented by the ThreadPool developers.
The user doesn't need to get into the threads! The developers should take care of that and write the corresponding classes.
The program runs in a single thread, while the regular non-blocking collabs are executed in a pool of threads!
Now replace your simple functions in colbacks with functions with heavy calculations or requiring concurrency.
Mega convenient and everything in parallel ))