Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Может перепроектируете этот кусок пока не поздно, ибо это баг?
Либо нужно возвращать управление из функции только после того, как хэндл указывает на валидные данные.
Либо возвращать иной код ошибки - указанный не соответствует по описанию: должно быть что-то вроде DATA_NOT_READY_YET. И еще тогда нужна функция типа WaitForSingleObject, т.к. Sleep - это кривизна: одни раз хватит 1 мс, в другой не хватит, а ставить с запасом - будут тормоза.
ИМХО.
Неплохо если бы разработчики сами WaitForSingleObject пользовались ...
Может перепроектируете этот кусок пока не поздно, ибо это баг?
Либо нужно возвращать управление из функции только после того, как хэндл указывает на валидные данные.
Либо возвращать иной код ошибки - указанный не соответствует по описанию: должно быть что-то вроде DATA_NOT_READY_YET. И еще тогда нужна функция типа WaitForSingleObject, т.к. Sleep - это кривизна: одни раз хватит 1 мс, в другой не хватит, а ставить с запасом - будут тормоза.
ИМХО.
Это - не баг, а реалии асинхронного мира. Предлагаете синхронизировать? Пожалуйста. Возьмите пример кастомного индикатора MACD и после получения хэндла машки поставьте ожидание заполнения данными. Накиньте индикатор на график и попереключайте таймфреймы. Насладитесь тормозами.
Чем Вас не устраивает ошибка ERR_INDICATOR_DATA_NOT_FOUND и зачем вводить какую-то новую?
Зачем городить WaitForSingleObject? Вы в курсе, что поток, вызвавший WaitForSingleObject, не будет получать никаких сообщений, пока не завершится этот самый WaitForSingleObject? Который может ждать бесконечно. И убить этот поток можно будет только самым зверским образом.
Гораздо проще завести все хэндлы в OnInit.
Что такое асинхронная обработка - я в курсе. Свои предложения я написал - там есть и синхронное, и асинхронное. Кастом MACD у меня есть, и на МТ4 он почти моментально переключается с одного таймфрйема на другой без тормозов (заранее не рассчитывался). МТ5 не ставил пока. Если Вы добавили тормозов в МТ5 - не стоит их решать за счет искусственного введения асинхронности, т.к. это дополнительный источник багов. Ваша задача написать такой инструментарий для трейдера, который бы помогал ему, а не палки в колеса вставлял. Я не против асинхронности, но нужно уметь её использовать и тем более предоставлять для её реализации соответствующие инструменты.
Ошибка ERR_INDICATOR_DATA_NOT_FOUND, судя по названию, предполагает, что данных в принципе нет. Вероятно, Вы планируете её возвращать в тех ситуациях, когда программист неправильно заполнил буфера или просто не произвел расчет. Ситуация, когда все было сделано правильно, но МТ еще в процессе рассчета (DATA_IS_BEING_CALCULATED), и нужно подождать и перезапросить данные чуть позже - сильно отличается. Если Вы не можете отличить одно от другого, то почему бы вообще не сделать одну единственную ошибку ERROR на все случаи жизни?
Под WaitForSingleObject я не имел в виду полную кальку с виндовой реализации. В частности, внутренний виндовый поток, обслуживающий работу скрипта, пусть крутится, а остановка касается только скриптового потока команд. Разработчики МТ вольны сделать блокировку в любой модели мультипоточности. Могут поместить весь код индюка в один эпартмент, а могут разделить по методам. Все это - последствия привнесенной асинхронности. Без проработки этих вещей асинхронность станет лишь источником ошибок. Данная тема - первое предупреждение.
Может перепроектируете этот кусок пока не поздно, ибо это баг?
Либо нужно возвращать управление из функции только после того, как хэндл указывает на валидные данные.
Либо возвращать иной код ошибки - указанный не соответствует по описанию: должно быть что-то вроде DATA_NOT_READY_YET. И еще тогда нужна функция типа WaitForSingleObject, т.к. Sleep - это кривизна: одни раз хватит 1 мс, в другой не хватит, а ставить с запасом - будут тормоза.
ИМХО.
Я вот то же думаю, что надо расширить коды ошибок. Ну и функцию-ожидалку сделать, ибо действительно Слип - кривизна.
До закрытого бета-тестирования у нас как раз и был реализован синхронный вариант - хэндл не возвращался до тех пор, пока не посчитаются данные. Получили реальные тормоза в кастомных индикаторах, которые используют данные других индикаторов (в частности MA).
Поэтому я и посоветовал: открывайте все хэндлы в OnInit, а пользуйтесь в OnTick, OnTimer или OnCalculate. В подавляющем большинстве случаев между вызовами данные уже посчитаются. Для проверки используйте функцию BarsCalculated
Я вот то же думаю, что надо расширить коды ошибок. Ну и функцию-ожидалку сделать, ибо действительно Слип - кривизна.
При правильном применении никакой кривизны нет. Например, Sleep(0) переключает контексты потоков и не даёт перегрузки процессора при бесконечном цикле.
Навскидку? Вы набросали пару общих фраз, не понимая о чём речь. Хотите многопотоковости? Запросто 2 эксперта - 2 потока, пусть обмениваются друг с другом сообщениями. "Работать синхронно с event loop" - это что? Это тот же самый цикл со слипом на миллисекунды!
Либо Вы не читали, что я написал двумя постами выше, либо Вы не понимаете проблемы. Давайте без навскидки алгоритм решения по пунктам.
Навскидку? Вы набросали пару общих фраз, не понимая о чём речь. Хотите многопотоковости? Запросто 2 эксперта - 2 потока, пусть обмениваются друг с другом сообщениями. "Работать синхронно с event loop" - это что? Это тот же самый цикл со слипом на миллисекунды!
Либо Вы не читали, что я написал двумя постами выше, либо Вы не понимаете проблемы. Давайте без навскидки алгоритм решения по пунктам.
Ну давайте, конкретная проблема: как мне распараллелить цикл вычислений? Только пожалуйста не надо "трейдеру этого не нужно".
Самое первое решение, лежащее на поверхности - можно использовать несколько кастомных индикаторов, рассчитываемых на разных символах-периодах. В этом случае они гарантированно работают в разных потоках. По окончании расчёта кастомный индикатор посылает эвент в окно с главным экспертом (ChartId может выступать в качестве одного из параметров индикатора). Как только эксперт получил все эвенты, он может пользоваться расчётами, запрашивая данные рассчитанных индикаторов.
Дополнение. ChartID можно не посылать. Кастомный индикатор, запущенный из-под эксперта и так будет знать ChartID родительского эксперта.