对OnBookEvent的订阅有时会脱落--有这种情况吗？ - 页 2

[A100]

Stanislav Korotky:

"只要有一位专家取消订阅，其他专家也会停止接收该事件"？

这是一个没有问题的问题

[Sergey Savinkin]

Stanislav Korotky:

这只是一个猜测，是否值得--在继续 "只需要一个EA取消接收事件，其他所有的EA也会停止接收 "的比喻？我认为不可能有这样的事情，这将是（或者说是）一个错误。

首先，它很容易检查。我想自己做，但我只有一个FORTS账户，而且周末关闭。

但如果是这样，情况就会变得很有趣。当你启用了专家顾问和指标，订阅就已经触发了。当你禁用专家顾问或指标时，你已经写了，订阅已经崩溃了。这表明，广播确实在相反的方向上发挥作用。现在想象一下，有些事情已经发生了变化（例如，历史已经改变，指标已经被重新计算）。但我们知道，OnInit和OnDeinit可以被随机调用。有时是正确的，有时反之亦然。如果图表先调用新版本的指标，然后再卸载旧版本的指标，会发生什么？订阅会脱落。这就是 "悄悄地掉下来 "的感觉。我建议你在OnInit和OnDeinit中放入打印机，以检查队列和消息，以防股票报价停止进入。也许这个问题会得到解决。

[A100]

Sergey Savinkin:

首先，这很容易检查。我想自己做，但我只有一个FORTS的账户，而且周末是关闭的。

你根本不需要CHARTEVENT_OBJECT_CREATE 来检查分数。

[Алексей Тарабанов]

https://yandex.ru/images/search?source=wiz&text=два%20выключателя%20на%20одну%20лампочку&img_url=https%3A%2F%2Frepair-need.ru%2Fuploads%2Fdico-kebfbf.jpg&pos=3&rpt=simage&lr=213

[TheXpert]

A100:
这是一个不难理解的问题。

我不明白，你总是可以把一个链接计数器

[A100]

TheXpert:

我不明白，你总是可以把一个链接计数器

没有计数器。如果有的话，在文档中会明确说明它的存在和只接受Add/Release对的调用--否则计数器会被破坏，它存在的意义也会消失。

如果你说你需要一个参考计数器...那么你可以更进一步，完全废除广播。

[TheXpert]

A100:

没有计数器。而如果有的话，在文档中会明确说明它的存在，并且只允许添加/释放配对调用--否则计数器会丢失，它存在的意义也会消失

而现在，发布功能是没有意义的，因为任何人都可以取消订阅你的事件的逻辑是无稽之谈。

[Ilya Baranov]

有一个简单的建议，就是干脆不使用MarketBookRelease 函数。

从理论上讲，这将浪费一些终端和服务器的资源。

但在实践中...这是否会有任何真正的后果？

[A100]

TheXpert:

现在发布功能已经没有意义了。因为任何人都可以取消订阅你的活动的逻辑是无稽之谈。

即使有一个计数器，任何人都可以根据需要多次 呼叫释放 来取消订阅--很可能计数器无法检测到额外的呼叫，目前的问题就会变成一个计数器故障的问题。如果你能使用一个智能计数器，你就可以取消这样的广播。

[Stanislav Korotky]

为刺猬解释是没有意义的，所以我就为别人写;-)。

事件广播的概念是一回事，但将订阅和取消订阅功能与事件配对的原则是另一回事。这些都是语义上独立的技术，它们不必，而且理想上也不应该相互影响。让事件被广播（这可能是出于效率的考虑，但这是非常有争议的，如果实施不当，会导致目前的问题）。这意味着只要有一个人订阅，所有的人都能收到该事件。但反过来说--一个人必须取消订阅，每个人都会被坑--这已经是某种狭义的广播了。

关于文档中用户的计数器没有提到，尽管它非常重要（关于广播的短语不是对上述原因的解释）。广播最好能持续到订阅者的数量减少到0。否则，很明显，MQL程序（包括来自不同开发者的程序）将不得不以某种方式相互沟通，以便不损害他们的工作，但这是无稽之谈。我不知道有哪个软件（广义的，不限于MT、Windows等）的订阅是以这种方式实现的。

有这样一段关于MarketBookRelease的内容。

Обычно эта функция должна вызываться из функции OnDeinit() в том случае, если в функции OnInit() была вызвана соответствующая функция MarketBookAdd().

这又是一个含糊不清的问题。它可以被解释为对订阅的数量有控制权。但该软件不允许私人解释。

底线，IMHO，实施是一个耙子（在MQL级别需要验证和超额订阅），文档是模糊的。恶意的或彻头彻尾的坏代码即使有计数器也能杀死别人的订阅，这种说法其实并不相关。所有这样的脚本都可能在终端的其他一堆地方造成伤害（例如，删除其他人的对象，在其他人的位置上杀死停止，等等，这在以前已经发生过无数次）。谈论这种彻头彻尾的捎带表现是没有意义的--除了用户纪律、校对其他用户的代码（如果有的话）或在演示中检查之外，它们是无法被阻止的。现在的问题是，正确编写的代码现在无法正常运行。

如果我们要正确地做这个机制，当然--发布者/订阅者模式并没有被废除。这当然不会影响效率。