Если бы я был архитектором QUIK

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

чтобы остановить выполнение потоко с колбеком надо в функцию колбека поставить sleep.
Поток колбека будет остановлен на время указанное в sleep.

    Когда же вы научитесь читать ? Вы читаете тексты перед тем как писать?
  Ведь написано:
 Где вы видите у меня фразу: "для исполнения"?  
 У вас какое то недержание ваших текстов.

TGB,
Если Вы знаете русский язык, то фраза
"до тех пор пока в потоке main не выполнится sleep или сишная функция"
означает, что время измеряется от некоторого момента до выполнения sleep  до момента окончания выполнения sleep.
-----------------
И понять эту фразу очень сложно.
Время до оператора  sleep     -   это время обработки очереди в цикле в main (пример есть в документации).  
Если бы в это время колбеки остановились, то никакой очереди создать было бы невозможно.
--------------------
момент времени после исполнения sleep   Если в sleep 0, то это практически время начала исполнения sleep  B этом случае оно совпадает с началом цикла обработки очереди.
-----------------------------
таким образом Вы сказали буквально следующее:  Колбеки всегда остановлены если в main нет функции sleep или параметр у нее равен нулю.
Но колбеки прекрасно работают и без sleep в main.
----------------------------
Согласитесь, что вы сказали чушь.

В песочнице QUIK 12.8.3.4 была создана заявка с номером 10256702148.
Она не удаляется ни вручную ни из скрипта.
 Выдается сообщение: "Не удалось снять заявку с номером 10256702148"
 Распечатка заявки из таблицы orders:
<code>
{--таблица: 18.02.26 13:04:52:795 - время создания.
  ['lseccode'] = [=[]=]
, ['qty'] = 7.0
, ['activation_time'] = 0
, ['accepted_uid'] = 0
, ['revision_number'] = 0
, ['sec_code'] = [=[YDEX]=]
, ['investment_decision_maker_short_code'] = 0
, ['visible_repo_value'] = 0.0
, ['accruedint'] = 0.0
, ['executing_trader_qualifier'] = 0
, ['trading_session'] = 0
, ['account'] = [=[NL0011100043]=]
, ['client_qualifier'] = 0
, ['operation_type'] = 0
, ['min_qty'] = 0.0
, ['ext_order_flags'] = 0
, ['client_code'] = [=[10379]=]
, ['price'] = 4917.0
, ['exchange_code'] = [=[]=]
, ['order_num'] = 10256702148
, ['passive_only_order'] = 0
, ['reject_reason'] = [=[]=]
, ['withdraw_datetime'] = { -- table: 00000171D1A2F9A0
 ['min'] = 0
, ['week_day'] = 1
, ['sec'] = 0
, ['ms'] = 0
, ['day'] = 1
, ['year'] = 1601
, ['mcs'] = 0
, ['month'] = 1
, ['hour'] = 0
 }
, ['visible'] = 0.0
, ['yield'] = 0.0
, ['settle_date2'] = 0
, ['price_currency'] = [=[]=]
, ['on_behalf_of_uid'] = 0
, ['awg_price'] = 0.0
, ['linkedorder'] = 0
, ['trans_id'] = 105007541
, ['start_date'] = 0
, ['firmid'] = [=[NC0011100000]=]
, ['value2'] = 0.0
, ['executing_trader_short_code'] = 0
, ['exec_type'] = 0
, ['extref'] = [=[]=]
, ['value'] = 34419.0
, ['repo_value_balance'] = 0.0
, ['repovalue'] = 0.0
, ['datetime'] = { -- table: 00000171D1A2FB20
 ['min'] = 36
, ['week_day'] = 3
, ['sec'] = 57
, ['ms'] = 0
, ['day'] = 18
, ['year'] = 2026
, ['mcs'] = 0
, ['month'] = 2
, ['hour'] = 6
 }
, ['class_code'] = [=[QJSIM]=]
, ['value_entry_type'] = 0
, ['settle_date'] = 0
, ['acnt_type'] = 0
, ['brokerref'] = [=[10379//1]=]
, ['start_discount'] = 0
, ['balance'] = 7.0
, ['side_qualifier'] = 0
, ['seccode'] = [=[YDEX]=]
, ['external_qty'] = 0.0
, ['benchmark'] = [=[]=]
, ['qty2'] = 0.0
, ['client_short_code'] = 0
, ['repoterm'] = 0
, ['price_entry_type'] = 0
, ['visibility_factor'] = 0.0
, ['ext_order_status'] = 0
, ['flags'] = 29
, ['settlecode'] = [=[]=]
, ['uid'] = 228221
, ['expiry'] = -1
, ['bank_acc_id'] = [=[]=]
, ['repo2value'] = 0.0
, ['capacity'] = 0
, ['ordernum'] = 10256702148
, ['price2'] = 0.0
, ['investment_decision_maker_qualifier'] = 0
, ['userid'] = [=[NC0011100000]=]
, ['expiry_time'] = -1
, ['canceled_uid'] = 0
, ['settle_currency'] = [=[]=]
, ['filled_value'] = 0.0
}--таблица: 18.02.26 13:04:52:795
<code>
----
Архив песочницы для анализа поддержкой: https://cloud.mail.ru/public/LTv3/NMDsG3SZD

  Здравствуйте! Спасибо за ответ.
  У меня просьба к вам: донести до разработчиков мои комментарии 1, 51.

      1. Я исхожу из того, что среди пользователей QUIK могут быть квалифицированные IT-разработчики, которые могут улучшить мои предложения и поэтому выкладываю их в публичку.
      2. Сохранение существующего API QLua, с тем, чтобы обеспечить совместимость с существующими разработками пользователей, является основным ограничением на предлагаемое.
-------------------
I.  В текущей версии QUIK в одном основном потоке обслуживаются:
- запуск всех Lua-скриптов пользователя;
- запуск коллбеков всех Lua-скриптов пользователя;
- обработка всех коллбеков таблиц QUIK (это не таблицы Lua);
- обработка всех индикаторов пользователя.
  Притом, что в текущий момент у подавляющего количества ПК много ядер ЦП, написанное выше явный перебор. Наверное, нет проблем перечисленное выше обрабатывать в отдельных потоках, так как перечисленные выше функции, в моем представлении, не сильно связаны друг с другом и, на первый взгляд, между ними не требуется синхронизация.

II. Интерфейс  взаимодействия QUIK c Lua-скриптом пользователя, реализованный в виде коллбеков, предполагает многопоточный режим использования Lua, порождающий неприятные проблемы параллельного программирования (для решения которых сами же разработчики предлагают использовать потокобезопасную очередь между коллбеками и потоком main). Мне представляется, что имеет смысл вместо коллбеков использовать активную очередь событий, При этом не требуется использовать Lua в многопоточном, редко используемом и не очень стабильном режиме. При этом не будет проблем с подключением новых версий Lua. Более того, скрипты пользователя будут выполняться несколько быстрее из-за отсутствия синхронизации, требуемой в многопоточном варианте использования  Lua.
  Конкретные предложения:
 1) Lua подключать в однопоточном режиме, нативном варианте, без внесения изменений в исходники. Все необходимые коды QLua перенести в dll-пакет.
 2) Для взаимодействия со скриптами пользователя использовать общие для них служебные циклические очереди (в соответствии с существующими функциями обратного вызова). Длины очередей задавать по умолчанию с возможностью их изменения пользователем. Для каждого запускаемого скрипта пользователя создавать блоки доступа (с соответствующими указателями, обеспечивающими чтение очередей без блокировки) к общим циклически очередям.
 3) Функции чтения очередей регистрировать под теми же именами и так же, как это делается для существующих коллбеков.
 4) Выполнять функции чтения очередей в модифицированной следующим образом sleep:
     - sleep выполняется по истечению заданного в ней интервала времени или при получения сигнала поступления данных в одну из циклических очередей (в пропуске сигналов нет проблем, так есть запуск по времени);
     - выполнение функции начинается с анализа появления новых данных в циклических очередях скрипта (конкретного) и запуска зарегистрированных его функций с теми параметрами из очередей, как это делается в существующей версии QUIK;
     - в качестве результата в модифицированной sleep выдавать значения: количество считанных записей в очередях, признак отсутствия потерь данных в очередях из-за их переполнения (с указанием очередей, в которых это возникло), и, возможно, еще что-то.
 Предложенное:
 1) устраняет зависимость служебного потока от пользовательского, когда (служебный) в существующей версии QUIK может быть блокирован пользовательским, а пользовательский служебным;
 2) устраняет необходимость внесения правок в исходники Lua; при этом скрипты пользователя будут выполняться несколько быстрее из-за отсутствия синхронизации, требуемой в многопоточном варианте использования Lua;
 3) обеспечивает контроль потерь данных в очередях, а также возможность исключения этих потерь за счет увеличения длин очередей пользователем или уменьшения времени ожидания в sleep;
 4) убирает проблемы синхронизации внутри скрипта пользователя.

III. В QUIK реализована функциональность просмотра графика котировок бумаг QUIK. Но отсутствует возможность просмотра котировок бумаг, сохраненных во внешних файлах. С учетом существующей функциональности QUIK, как мне представляется, реализация этой возможности не потребует больших усилий.

IV. Пожелание: сократить время восстановления взаимодействия QUIK с сервером при перезапуске хотя бы до 10 сек.

   Я так понимаю, в случае реализации предложенного.

У пользователя никаких изменений:

  Да, так называемые коллбеки, должны вызываться внутри sleep (выполняемой в потоке main) с данными из очередей.

  При "просыпании" sleep, функции чтения очередей (коллбеки) будут выполняться (последовательно, без пропусков) столько раз сколько необработанных записей в очередях. Если очереди не переполняются, а это можно контролировать и не допускать, то события не теряются, но возможны задержки в их отработке.
  Как было указано ранее, sleep "просыпается" либо по времени, либо по записи в очереди данных из QUIK. Но при этом в в sleep всегда анализируются и при необходимости обрабатываются непустые служебные очереди скрипта.

 Если вы не хотите повторно обрабатывать данные, то фильтруйте их. Для фильтрации данных можно создать, для соответствующего вида коллбека, таблицу с фильтруемыми полями, обновляемыми при поступлении новых данных и использовать эту таблицу в начале коллбека с тем. чтобы не обрабатывать ненужные вам повторы.

   Вы сначала создаете таблицу фильтрации со значениями полей фильтрации заведомо не совпадающими с ожидаемыми данными.

   Вы опять только пишите не читая.
   Мы же с Йцукен обсуждаем не системный Sleep и даже sleep QLua, а предложенный мной запускающий коллбеки.
Вам опять надо проложиться между комментариев ?

Что вы так переживаете?
Я написал пояснение о работе sleep в потоках.
Так как г-н Йцукен нефига в этом не понимает, а Вы ему ( я прочитал Ваш ответ)
Это полная чушь.
Ничего внутри sleep не вызывается т к функция sleep выполняется ядром OS.  В это время никакой колбек не успеет ничего сделать.
-------------------
 

  Вы, как дятел , про свое, не относящееся к обсуждаемому.
  Вы это читали ?:

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

Ну т.е., фактически запросить данные, обработать их (как минимум сравнить с предыдущими).
Логичней было бы, чтобы терминал не дублировал пропущенные колбэки, по которым скрипт не получит новых данных.
Хотя, кому-то наоборот нужна вся история изменений (для индикатора какого-нибудь). Не зря же есть CreateDataSource для параметров инструментов. Но тогда QUIK должен хранить всю историю изменений.
В общем, этот момент вам надо продумать.