Asynchronous and multi-threaded programming in MQL - page 7
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
Well, I'm not, you know, a do-it-yourself guy either )). I'm very likely to be able to call µl functions from dll, but most likely there will be a problem - after each start I need to dig under the debugger. All in all, not much of an option.
It's not about you or me! It's about the IT industry itself, methods of protection have long been invented and are constantly being improved, there are those who do the protection and those who "test" it
And my imho, if you see another article about another PlayStation / XBox hack, then someone needs it! - Mayakovsky )))) - this is a marketing strategy of an IT giant and not another clever hacker who managed to find a vulnerability - yes there are bugs in software, vulnerabilities happen but there are also marketing strategies that raise interest in software
;)
Imho, you overestimate the complexity of the task (yank mcl from dll), but the solution is complicated and inconvenient (why sit in debugger after each run?). Much more elegant - think of a protocol for the exchange between the service in the terminal and third-party program via sockets, write the C and mkl part, and put it in the free, open access. That's all, you don't even need to break anything.
it's not clear what this will do?
As the developers say, it is not possible to go beyond the "MQL sandbox" for each program, so what will it bring you through sockets to TCP?
you will not get to another MQL program without the source code modification, the same way where we started - you won't be able to call any MQL function from a dll.
or are we talking about remote control of an MQL program? - That's never been a problem, we develop our own exchange protocol and control what we can.
It's about "making a semblance of API", universal. Hook a lib to a cross program, and get data/send requests. And it's going to be mature, without any sandboxes and "caring" about my security. And there's no need to manage anything - just data and requests. Soon this facility will be filled with all sorts of meat - such as charts with technical analysis.
But the audience here is not the same - the sellers and the buyers of the market.
Igor Makanu:
The MQL-programs with dll are not popular on the Net, just in case... Maybe you did not do it on purpose, but your computer is ill with whatever and together with your dll you are sending a bunch of viruses to your user's PC ... In general, the developers promised maximum protection for the end user, i.e. the trader.
It's all a crappy Windows, although they seem to have cleaned it up.
I'm not afraid to run any executable on my Linux - running it without administrator rights this software can't even do anything wrong. I've forgotten about viruses along with the virus.
It's all the screwed up windup, although they seem to have cleaned it up as well.
I'm not afraid to run any application on my linux at all
Got it)))
If the mql language implements the functionality to work with asynchronous code, then we can translate the work of indicators out of the box into asynchronous mode and get rid of the threading problem.
After solving the issue of multi-threading of indicators, you can safely implement tick-charts. The whole chain is interconnected.
Asynchronous mode will give a new impetus to the development of writing fast programs. It will solve the problem of expanding to tick charts.
Asynchrony will give a new impetus to the development of writing fast programs.
Given the qualifications of the people here, this is more of an almost guaranteed way of shooting yourself in the foot.
And those who really consciously need asynchrony and multithreading for themselves have no problem implementing it with available means.
Given the skills of the people here, this is almost a guaranteed way to shoot yourself in the foot.
And those who really consciously need asynchrony and multithreading for themselves have no problem implementing it with the means available.
Let such individuals shoot themselves in the head at once. It is not the problem of the developers and their product...
To learn and understand the principle of asynchronous mode is like two fingers on the asphalt, it is not streams. And if it is difficult, there is nothing to get into.
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.
I read the smart participants and I wonder...
What's the point of all these gimmicks?
When in MQL would the multi-threading be so terribly needed? To me, the only use would be strategy testing, which is implemented in the standard way.
The idea is that it might make sense to run several WebRequests, but I don't think multi-threading is needed at all.
What tasks require multithreading in the first place?
George, the point of anything can always be derailed. And there's nothing to counter this approach. And why would a man need money if he's going to die anyway? Everyone is going to die anyway, why do we need the market, algotrading and so on?
Having an in-house multi-threading facility in MQL would be very cool. Understand, this is a creative testing ground for many. The question "why?" is not always appropriate.