Подписка на OnBookEvent иногда отваливается - есть такое? - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
"достаточно одному эксперту отписаться от получения события, как все остальные эксперты тоже перестанут его получать"?
Вот только по ней остается догадываться, стоит ли или нет - по аналогии продолжить, что "достаточно одному эксперту отписаться от получения события, как все остальные эксперты тоже перестанут его получать"? Я считаю, что такого не может быть, это был бы (или есть) баг.
Во-первых, это легко проверить. Я бы и сам это сделал, но у меня счет только на FORTS, а он в выходные закрыт.
Но если это так, то ситуация получается забавная. Включили Вы эксперт, индикатор, подписки сработали. Отключили эксперт или индиктатор - уже писали, что подписка отвалилась. Это наводит на мысль о том, что широковещательность все же работает и в обратную сторону. А теперь представьте, что что-то изменилось (например, поменялась история и индикатор пересчитался). Но мы же знаем, что OnInit и OnDeinit могут вызываться произвольным образом. Когда-то правильно, а когда-то и наоборот. Что произойдет, если график сначала вызовет новую версию индикатора, а потом - деинсталлирует старую? Подписка отвалится. Это и будет похоже на "отвал по-тихому". Я бы рекомендовал Вам поставить принты в OnInit и OnDeinit, чтобы проверить очередность и сообщение в случае прекращения поступления котировок по стакану. Возможно, проблема прояснится.
Во-первых, это легко проверить. Я бы и сам это сделал, но у меня счет только на FORTS, а он в выходные закрыт.
Чтобы проверить счет вообще не нужен. CHARTEVENT_OBJECT_CREATE такое же широковещательное событие
Это и ежу понятно
непонятно. всегда можно навесить счетчик ссылок
непонятно. всегда можно навесить счетчик ссылок
Счетчика нет. А если бы он был то в документации было бы явно указано о его существовании и допустимости только парного вызова Add\Release - иначе счетчик собьется и потеряется смысл его существования
А если Вы говорите что нужен счетчик ссылок... тогда можно пойти дальше и вообще отменить широковещательную передачу
Счетчика нет. А если бы он был то в документации было бы явно указано о его существовании и допустимости только парного вызова Add\Release - иначе счетчик собьется и потеряется смысл его существования
ну а сейчас теряется смысл в функции release. потому что логика по которой кто угодно может отменить твою подписку на событие это бредовая логика
Есть простое предложение просто не использовать функцию MarketBookRelease.
Теоретически от этого будет впустую расходоваться часть ресурсов терминала и сервера.
Но на практике... Будут ли от этого реальные последствия?
ну а сейчас теряется смысл в функции release. потому что логика по которой кто угодно может отменить твою подписку на событие это бредовая логика
Для ежей бессмысленно что-то объяснять, так что я напишу для остальных ;-).
Понятие широковещательности события - это одно, а принципы парного вызова функций подписки и отписки на событие - это другое. Это независимые по смыслу приемы, которые не обязаны, а в идеале - не должны влиять друг на друга. Пусть событие будет широковещательным (наверняка это делалось из соображений яко-бы эффективности, но это очень спорно и при неверной реализации может порождать текущую проблему). Это значит, что достаточно одному подписаться, чтобы события стали получать все. Но вот в обратную сторону - достаточно одному отписаться и наступают кранты для всех - это уже какая-то узковещательность.
Про счетчик подписчиков в документации не сказано ни слова, хотя это очень важно (и фраза про широковещательность не является объяснением по вышеуказанной причине). По хорошему, широковещательная рассылка должна продолжаться до тех пор, пока количество подписчиков не уменьшится до 0. Иначе очевидно, что MQL программы (в том числе от разных разработчиков) должны были бы как-то общаться между собой, чтобы не навредить своей работе, но это нонсенс. Я не знаю ни одного примера ПО (в широком смысле, не ограничиваясь МТ, Windows и пр.), в котором подписка было бы реализована таким образом.
Есть такой пассаж про MarketBookRelease:
Обычно эта функция должна вызываться из функции OnDeinit() в том случае, если в функции OnInit() была вызвана соответствующая функция MarketBookAdd().
Он опять-таки двусмысленный. Это можно трактовать как наличие контроля числа подписок. Но ПО не допускает частных трактовок.
Итого, ИМХО, реализация - с граблями (на уровне MQL требуется делать проверку и переподписку), документация - мутная. Утверждение, что злонамеренный или откровенно лажовый код может поубивать подписки других даже при наличии счетчика, не совсем относится к делу. Все подобные скрипты могли бы навредить в куче прочих мест в терминале (например, поудалять чужие объекты, поубивать стопы у чужих позиций и пр., что уже миллион раз бывало). Про такие откровенно свинские проявления бессмысленно говорить - их невозможно предупредить ничем, кроме дисциплины пользователя, вычитки чужого кода (если он есть) или проверки на демке. Проблема сейчас в том, что правильно написанный код не может сейчас нормально выполняться.
Если бы делать сей механизм грамотно, то конечно - паттерн публикатора/подписчика никто не отменял. На эффективности он бы точно не сказался.