Не вьехал по МТ-5 - страница 2

Неплохо если бы разработчики сами WaitForSingleObject пользовались ...

Это - не баг, а реалии асинхронного мира. Предлагаете синхронизировать? Пожалуйста. Возьмите пример кастомного индикатора 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 я не имел в виду полную кальку с виндовой реализации. В частности, внутренний виндовый поток, обслуживающий работу скрипта, пусть крутится, а остановка касается только скриптового потока команд. Разработчики МТ вольны сделать блокировку в любой модели мультипоточности. Могут поместить весь код индюка в один эпартмент, а могут разделить по методам. Все это - последствия привнесенной асинхронности. Без проработки этих вещей асинхронность станет лишь источником ошибок. Данная тема - первое предупреждение.

Я вот то же думаю, что надо расширить коды ошибок. Ну и функцию-ожидалку сделать, ибо действительно Слип - кривизна.

До закрытого бета-тестирования у нас как раз и был реализован синхронный вариант - хэндл не возвращался до тех пор, пока не посчитаются данные. Получили реальные тормоза в кастомных индикаторах, которые используют данные других индикаторов (в частности MA).

Поэтому я и посоветовал: открывайте все хэндлы в OnInit, а пользуйтесь в OnTick, OnTimer или OnCalculate. В подавляющем большинстве случаев между вызовами данные уже посчитаются. Для проверки используйте функцию BarsCalculated

При правильном применении никакой кривизны нет. Например, Sleep(0) переключает контексты потоков и не даёт перегрузки процессора при бесконечном цикле.

При правильном применении проблема асинхронности решается потоками, их видать в языке нет. Еще одна возможность - работать синхронно с event loop. Ее тоже нет. MessageQueue? Это так, навскидку. По-моему я понял, почему тут программистов не жалуют ...

Навскидку? Вы набросали пару общих фраз, не понимая о чём речь. Хотите многопотоковости? Запросто 2 эксперта - 2 потока, пусть обмениваются друг с другом сообщениями. "Работать синхронно с event loop" - это что? Это тот же самый цикл со слипом на миллисекунды!

Либо Вы не читали, что я написал двумя постами выше, либо Вы не понимаете проблемы. Давайте без навскидки алгоритм решения по пунктам.

Ну давайте, конкретная проблема: как мне распараллелить цикл вычислений? Только пожалуйста не надо "трейдеру этого не нужно".

Самое первое решение, лежащее на поверхности - можно использовать несколько кастомных индикаторов, рассчитываемых на разных символах-периодах. В этом случае они гарантированно работают в разных потоках. По окончании расчёта кастомный индикатор посылает эвент в окно с главным экспертом (ChartId может выступать в качестве одного из параметров индикатора). Как только эксперт получил все эвенты, он может пользоваться расчётами, запрашивая данные рассчитанных индикаторов.

Дополнение. ChartID можно не посылать. Кастомный индикатор, запущенный из-под эксперта и так будет знать ChartID родительского эксперта.