"Распоточитваются" ли вызовы start() в советниках?

Новый комментарий
 
Можете ли Вы подсказать, как организована работа советников?
Функция start() вызывается при каждом новом тике.
А эти вызовы выполняются в отдельных потоках или нет?
У нас на каждый тик выполняются вычисления и когда тиков много (до 50 по архиву МТ),
то функция start() вызывается гораздо меньшее кол-во раз.
Может ли быть так, чтобы start() еще не отработал и пришедший следующий тик просто потерялся, т.е. по нему не была вызвана функция start()?

Короче, как реализовано? Каждый вызов start() - отдельный поток или нет?
 
"MQL4: Выполнение программ"

=== цитата ===
...Если при поступлении новой котировки выполнялась функция start(), запущенная на предыдущей котировке, то пришедшая котировка будет проигнорирована советником. Все пришедшие во время выполнения программы новые котировки программой игнорируются до тех пор, пока не завершится очередное выполнение функции start()...
===
 
Да, каждый эксперт гарантированно выполняется в отдельных потоках.
 
Спасибо! Это очень полезная информация.

Но тогда становится непонятно, в принципе возможно ли обработать все тики (так, чтобы это было гарантировано)?

Именно в рамках советника, который на тики реагирует функцией start()?
 
"MQL4: Выполнение программ"

=== цитата ===
...Если при поступлении новой котировки выполнялась функция start(), запущенная на предыдущей котировке, то пришедшая котировка будет проигнорирована советником. Все пришедшие во время выполнения программы новые котировки программой игнорируются до тех пор, пока не завершится очередное выполнение функции start()...
===



Можете прояснить: это только к советникам или к индикаторам тоже относится? Или так: возможна ли ситуация, что индикатор так загрузит машину, что до советника не дойдет вообще? Или все же пришедший тик пройдет по цепочке - тик-индикатор(ы)-советник?
 
Но тогда становится непонятно, в принципе возможно ли обработать все тики (так, чтобы это было гарантировано)?

Точный ответ процитировал wellx.
 
Можете прояснить: это только к советникам или к индикаторам тоже относится? Или так: возможна ли ситуация, что индикатор так загрузит машину, что до советника не дойдет вообще? Или все же пришедший тик пройдет по цепочке - тик-индикатор(ы)-советник?

Только к советникам. Если эксперт не завершил функцию start до прихода следующей котировки, то эксперт пропустит вызов на этой новой котировке.

Индикаторы работают в интерфейсном потоке и никак не распараллеливаются. Если индикатор тратит много времени, то он тормозит терминал. Индикатор, вызванный из эксперта, работает в потоке самого эксперта.
 
Тогда к разработчикам возникает вопрос.
Ибо только они знают, что внутри МТ.
Как можно (через какой механизм) реагировать на каждый тик (гарантированно)?
Через советника? Через DDE? Через внешнее приложение? Как-то еще?
Могли бы Вы реализовать очередь тиков для того, чтобы они не терялись (и не обрабатывались),
пока, например, функция start() не вернула управление.
 
ответ очевиден, чтобы реализовать запись и обработку всех тиков используй индикатор пишущий в файл, а экспертом обрабатывай этот файл
 
ответ очевиден, чтобы реализовать запись и обработку всех тиков используй индикатор пишущий в файл, а экспертом обрабатывай этот файл


По -моему, назрел вопрос разработки не 5го МТ и языка, а скорее версии 4.5. в котрой должно появиться наборы обратных функций для корректной работы с терминалом различных советников. В частности :
- проверка состояния коннекта
- работа нескольких советников (мьютексы и т.д., но управляемые терминалом , а не доморощенными советниками)
- статус наличия пропущенных тиков
......

может разработчикам сделать опрос реальных программеров на предмет чего им не хватает сейчас? Раз уж клиентского апи нет. Мне кажется только после повышения юзабельности терминала с точки зрения программирования можно начинать разработку нового варианта языка. Это реально поможет выработать полезное ТЗ на сам язык.
 
ответ очевиден, чтобы реализовать запись и обработку всех тиков используй индикатор пишущий в файл, а экспертом обрабатывай этот файл


Знаете.... так и делаем фактически, но.... не всё успевает записаться....
теряем тики... теряем.... и по DDE теряем и через советника теряем...

Но такое должно реализовываться через механизмы очереди, ибо на каждый тик заводить отдельный поток вроде не рационально.

Полностью поддерживаю необходимость проверки статуса коннекта, пропущенных тиков, работы нескольких советников.

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

МТ4 после обновления очень сильно начинает "глючить".
Сначала думал, дело в wine. Запустил всё под "виндой", оказось и там,
что до обновления нормально работает коннект, а после обновления начинает
теряться... просто периодичсекие пропадает и заново восстанавливается, а до
обновления этого нет.

И по поводу данных. Это реальная проблема для тех, кто основывается на данных и пишет свой софт. Клиентского апи нет, а доступные DDE и советники работают не так, как от них ожидаешь.

Очень надеюсь на какие-то изменения в этих вопросах от разработчиков.
Новый комментарий
Причина обращения: