Subscription to OnBookEvent sometimes falls off - is there such a thing? - page 2
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
"all it takes is for one expert to unsubscribe from receiving the event, and all the other experts will stop receiving it too"?
It's just a guess as to whether it's worth it or not - in the analogy of continuing that "all it takes is for one EA to unsubscribe from receiving an event, and all other EAs will stop receiving it too"? I don't think there can be such a thing, it would (or is) a bug.
For one thing, it's easy to check. I would do it myself, but I only have a FORTS account and it's closed at the weekend.
But if so, the situation turns out to be funny. When you have enabled Expert Advisor and indicator, the subscriptions have triggered. When you disable the Expert Advisor or the indicator, you have already written that the subscriptions have crashed. This suggests that broadcasting does work in the opposite direction. Now imagine that something has changed (e.g. the history has changed and the indicator has recalculated). But we know that OnInit and OnDeinit can be called randomly. Sometimes it is correct, and sometimes it is vice versa. What will happen if the chart calls the new version of the indicator first, and then it uninstalls the old one? The subscription will fall off. That's what it would be like to "fall off quietly". I would recommend that you put printers in OnInit and OnDeinit to check the queue and message in case quotes on the betting window stop coming in. Perhaps the problem will clear up.
First of all, it's easy to check. I would do it myself, but I only have an account on FORTS and it is closed at the weekend.
You don't needCHARTEVENT_OBJECT_CREATE to check the score at all.
It's a no-brainer.
I don't understand. You can always put a link counter
I don't understand. You can always put a link counter
There is no counter. And if there was it would be explicitly stated in documentation about its existence and admissibility of Add\Release pair call only - otherwise the counter will be broken and the meaning of its existence will be lost
And if you say that you need a reference counter... then you could go further and abolish broadcasting altogether
There is no counter. And if there was one, it would be explicitly stated in the documentation that it exists and only Add/Release paired call is allowed - otherwise the counter will be lost and the meaning of its existence will be lost
and right now the release function is meaningless because the logic that anyone can unsubscribe from your event is nonsense.
There is a simple suggestion to simply not use theMarketBookRelease function.
In theory, this would waste some of the terminal and server resources.
But in practice... Will there be any real consequences from this?
Well now there is no point in the release function. because the logic that anyone can unsubscribe from your event is nonsense logic
It's pointless to explain for hedgehogs, so I'll write for others ;-).
The notion of event broadcasting is one thing, but the principles of pair-calling the subscribe and unsubscribe functions to an event is another. These are semantically independent techniques which don't have to, and ideally shouldn't, affect each other. Let the event be broadcast (this was probably done for efficiency reasons, but it's very controversial and can cause the current problem if implemented incorrectly). This means that it is enough for one to subscribe, for all to receive the event. But in reverse - one has to unsubscribe and everyone gets screwed - it's already some kind of narrowcasting.
About the counter of subscribers in documentation is not mentioned, although it's very important (and the phrase about broadcasting is not an explanation for the above reason). Broadcasting should ideally last until the number of subscribers decreases to 0. Otherwise, it's obvious that MQL programs (including those from different developers) would have to communicate with each other somehow, so as not to harm their work, but this is nonsense. I don't know of a single example of software (in the broad sense, not limited to MT, Windows, etc) where subscription was implemented in this way.
There's this passage about MarketBookRelease:
Обычно эта функция должна вызываться из функции OnDeinit() в том случае, если в функции OnInit() была вызвана соответствующая функция MarketBookAdd().
It is, again, ambiguous. It could be interpreted as having control over the number of subscriptions. But the software doesn't allow private interpretations.
Bottom line, IMHO, implementation is a rake (verification and oversubscription is required at MQL level), documentation is murky. The assertion that malicious or outright bad code can kill others' subscriptions even with a counter is not really relevant. All such scripts could do harm in a bunch of other places in the terminal (e.g. delete other people's objects, kill stops on other people's positions, etc., which has happened a million times before). There is no sense in speaking about such outright piggyback manifestations - they cannot be prevented by anything except user discipline, proofreading of other user's code (if there is any) or checking on a demo. The problem now is that properly written code cannot run properly now.
If we were to do this mechanism properly, of course - the publisher/subscriber pattern has not been abolished. It would certainly not affect efficiency.