Отладка QUIK 8.13

Страницы: Пред. 1 2 3 4 След.
RSS
Отладка QUIK 8.13
 
Цитата
Roman Azarov написал:
Просьба сделать как с предыдущими пожеланиями, собрать само пожелание (что конкретно, по Вашему, необходимо доработать и каким образом), его актуальность и все комментарии к нему в одном сообщении.Обязательно его зарегистрируем.
   Просьба устранить ошибки, описанные в ветках (там много комментариев и повторять их полностью здесь, наверное не стоит):
1) Опять ошибка получения кол-ва ордеров скриптом https://forum.quik.ru/forum10/topic6503/ ;
2) [BUG] getFuturesHolding: ошибка в работе https://forum.quik.ru/forum10/topic6526/ .
  Ошибки, описанные в упомянутых выше ветках, скорее всего, ошибки синхронизации функций API QLua. И ошибки такого вида, возможно, имеются и в других функциях API.
  Вообще, все функции API работы с QUIK из QLua должны быть потокобезопас-ными  из-за того, что к ним могут обращаться из нескольких одновременно запущенных скриптов (работающих в разных потоках).
     Написанное в упомянутых выше ветках (с приведением кодов и результатов), демонстрирует, что getDepoEx и getFuturesHolding не являются потокобезопасными.
------
    Возможно, то, что написано далее, разработчики QUIK хорошо понимают, но на всякий случай некоторые соображения.
 Объекты синхронизации функций API QLua должны локализоваться в месте, общем для всех скриптов пользователя, и это место точно не global_State и тем бо-лее не lua_State. На месте разработчиков QUIK, я бы создал общий для всех скриптов пользователя массив, в котором для каждой функции API QLua выделил элемент хранения объекта синхронизации при работе с этой функцией. Синхронизация должна выполняться не только при обращении к функциям API, но в соответствующих программах, готовящих данные для обсуждаемых функций в потоках отличных от пользовательских.
 
TGB, здравствуйте!

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

Как только разбор ситуации подойдет к концу, мы дадим ответ в соответствующих темах.
 
Я пытаюсь помочь решить наши с вами проблемы потокобезопасности API QLua работы с QUIK.
 Если синхронизация функций API реализована так:
Цитата
TGB написал:
Объекты синхронизации функций API QLua должны локализоваться в месте, общем для всех скриптов пользователя, и это место точно не global_State и тем бо-лее не lua_State. На месте разработчиков QUIK, я бы создал общий для всех скриптов пользователя массив, в котором для каждой функции API QLua выделил элемент хранения объекта синхронизации при работе с этой функцией. Синхронизация должна выполняться не только при обращении к функциям API, но в соответствующих программах, готовящих данные для обсуждаемых функций в потоках отличных от пользовательских.
то тех "плавающих" результатов, которые описаны в ветках:
1) Опять ошибка получения кол-ва ордеров скриптом https://forum.quik.ru/forum10/topic6503/ ;
2) [BUG] getFuturesHolding: ошибка в работе https://forum.quik.ru/forum10/topic6526/ .
по моим представлениям, быть не должно.
 Пусть мне кто-то объяснит, что я ошибаюсь.
 
TGB,

Спасибо, мы постараемся учесть Ваши дополнения при разборе описанных обращений.
 
TGB, Добрый день, Действительно, в ПО QLUA есть ошибка одновременной работы скриптов использующих лимиты. Мы исправим её в очередном обновлении ПО. Приносим извинения за причинённые неудобства.
 
Цитата
Roman Azarov написал:
27.04.2021 06:18:12
TGB , добрый день!Оба пожелания зарегистрированы, мы постараемся их рассмотреть. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожеланий в будущих версиях ПО.Каких-либо сроков назвать не можем. Как будет результат анализа пожеланий, мы сообщим Вам в данной теме.
  Прошло два месяца.
Просьба к поддержки: сообщить результаты рассмотрения пожеланий.
----
 Второе пожелание факультатив и, наверное, его стоит рассматривать после устранения критических ошибок, но первое пожелание (было отмечено сразу при описании пожеланий) это устранение ошибки.
 Напоминаю:
  Бывают ситуации зависания в QLua, когда основной поток обслуживания колбеков всех скриптов пользователя, а также таблиц QUIK (это не таблицы Lua), блокируется выполнением  длинного цикла пользовательской программы на «чистом» Lua, в котором нет ни вызова seep ни вызова других C-функций.
 Это может порождать ошибки, которые для многих пользователей QLua (использующих несколько запускаемых скриптов)  являются неожиданными и труднообъяснимыми. Блокируются выполнения колбеков всех скриптов из-за выполнения длинного цикла пользовательской программы на «чистом» Lua в каком-то из запущенных пользователем скриптов.
-----
 Есть простой вариант реализации первого пожелания, кстати, совместимого со вторым  (далее список изменений реализующих этот вариант в в тексте исходни-ков Lua ):
1. В файле   lstate.h  после строки:  lu_byte allowhook;
добавить: int Счетчик_для_переключения_State;
2. В файле   lstate.с  после строки:  L->errfunc = 0;
добавить:  L->Счетчик_для_переключения_State = 0;
3. В файле   lstate.с  после строки:  L1->stacksize = BASIC_STACK_SIZE;
добавить:  L1->Счетчик_для_переключения_State = 0;
4. В файле   lvm.с  после строки:  StkId ra;
добавить:  
if (++L->Счетчик_для_переключения_State > 1000) {   //  1000  надо задать кон-стантой   L->Счетчик_для_переключения_State = 0;
lua_unlock(L); lua_lock(L);
}
------------------------------------  
 В чем проблема реализации первого пожелания?
 
Цитата
TGB написал:
Текст данного комментария со Старателем не согласован, но надеюсь, что если, по его мнению, я написал что-то не то, он меня поправит.
---------
  Предложение1 (от Старателя).
     Мое краткое описание ситуации, устраняемое при реализации предложения Старателя, а далее цитаты.
     Бывают ситуации зависания в QLua, когда основной поток обслуживания колбеков всех скриптов пользователя, а также таблиц QUIK (это не таблицы Lua), блокируется выполнением  длинного цикла пользовательской программы на «чистом» Lua, в котором нет ни вызова seep ни вызова других C-функций.
----
   Далее цитирую Старателя:
«Если цикл продолжительный, чтобы не было зависаний, можно вставить внутрь цикла любую с-функцию (не обязательно sleep). Причём, вставлять можно не на каждую итерацию, а через задан-ное количество циклов. Это позволит не подвешивать основной поток и при этом сохранить ско-рость вычислений байткода в циклах.».
---
 Далее цитирую себя:
Комментарий 1.
«То, что предлагает Старатель, наверное, имеет смысл реализовать в самом QLua.

Всё же вставлю свои "пятькопеек".
В текущей реализации QLua (5.3/5.4) задача легко решаема на уровне пользовательского скрипта методом, предложенным мной выше, что позволяет при необходимости снять блокировку в любом месте цикла.
Это позволяет скриптеру писать байткод-циклы (в текущей версии QLua 5.3/5.4), выполняющиеся атомарно (читай потокобезопасно).
При реализации вашего пожелания на уровне QLua скриптер лишится такой возможности.
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Цитата
Старатель написал:
Это позволяет скриптеру писать байткод-циклы (в текущей версии QLua 5.3/5.4), выполняющиеся атомарно (читай потокобезопасно).
 При реализации вашего пожелания на уровне QLua скриптер лишится такой возможности.
--
 В документе разработчика QUIK: «Использование Lua в Рабочем месте QUIK.pdf», в разделе «2. Взаимодействие потоков Lua скрипта» описана рекомендуемая схема обработки колбеков. Если придерживаться ее, то проблем многопоточности (! из-за основного потока обработки колбеков) в скрипте пользователя не будет вообще: ни в «чистом» Lua-коде ни в смешанном.
 
Цитата
TGB написал:
 В документе разработчика QUIK: «Использование Lua в Рабочем месте QUIK.pdf», в разделе «2. Взаимодействие потоков Lua скрипта» описана рекомендуемая схема обработки колбеков.
Иногда в скрипте требуется что-то большее, чем просто в одном потоке засунуть значение в табличку и вытащить его в другом.
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Цитата
Старатель написал:
Иногда в скрипте требуется что-то большее, чем просто в одном потоке засунуть значение в табличку и вытащить его в другом.
 Какие ограничения накладывает рекомендуемая разработчиком QUIK схема обработки колбеков на обработку данных в скрипте пользователя?
 
TGB,
как вариант, или многоуровневые таблицы, или одно событие может менять состояние нескольких таблиц...
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Цитата
Старатель написал:
как  вариант , или многоуровневые таблицы, или одно событие может менять состояние нескольких таблиц...

 Любой существующий скрипт, в котором нет очереди  между вызовами колбеков и их обработкой, легко может быть преобразован в вариант скрипта, схема работы с колбеками которого, описана в разделе «2. Взаимодействие потоков Lua скрипта». Поэтому никаких функциональных ограничений данной схемой не накладывается. При этом, так как работа с очередями потокобезопасна, а вся остальная обработка выполняется только в main, то никаких конфликтов скрипта пользователя с основным потоком вызова колбеков не может быть.
-------------------------------------------
  Из раздела «2. Взаимодействие потоков Lua скрипта».

Пример реализации очереди FIFO («первым пришёл — первым ушёл») для обработки
срабатывания функций обратного вызова в функции main():
Код

function OnInit(script)
 is_run = true
 MAIN_QUEUE = {}
end

function OnOrder(order)
table.sinsert(MAIN_QUEUE, {callback = "OnOrder", value = order})
end

function OnTrade(trade)
   table.sinsert (MAIN_QUEUE, {callback = "OnTrade", value = trade})
end

function OnAllTrade(all_trade)
table.sinsert(MAIN_QUEUE, {callback = "OnAllTrade", value = all_trade})
end

function OnQuote(class_code, sec_code)
local quote = getQuoteLevel2(class_code, sec_code)
table.sinsert(MAIN_QUEUE, {callback = "OnQuote", value = quote})
end

function OnStop()
is_run = false
return 2000
end

function main()
  while is_run do
    if #MAIN_QUEUE > 0 then
       ProcessingCallbakc(MAIN_QUEUE[1])
       table.sremove(MAIN_QUEUE, 1)
       message("Размер очереди " .. tostring(#MAIN_QUEUE))
    end
 end
end

function ProcessingCallbakc(value)
  message(string.format("Обработка события %s начата", value.callback))
  sleep(3000) --эмуляция продолжительного алгоритма обработки события
  message(string.format("Обработка события %s завершена", value.callback))
end
 
Цитата
TGB написал:
Бывают ситуации зависания в QLua, когда основной поток обслуживания колбеков всех скриптов пользователя, а также таблиц QUIK (это не таблицы Lua), блокируется выполнением  длинного цикла пользовательской программы на «чистом» Lua, в котором нет ни вызова seep ни вызова других C-функций.

Держите и вы от меня "шайбу":
Цитата
Старатель написал:
чтобы не было зависаний, можно вставить внутрь цикла любую с-функцию (не обязательно sleep). Причём, вставлять можно не на каждую итерацию, а через заданное количество циклов. Это позволит не подвешивать основной поток и при этом сохранить скорость вычислений байткода в циклах.
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Цитата
Старатель написал:
Держите и вы от меня "шайбу":
     Есть все-таки большая разница между «шайбами»:
1) перешел один раз на схему, рекомендуемую разработчиком QUIK, и далее проблемами конфликтов с основным потоком запуска колбеков не заморачиваешся;
2) всякий раз при изменении/добавления кода скрипта анализируй участки кода на предмет его потокобезопасности да еще и вставляй прокладки для защиты от блокировок.
 
Цитата
TGB написал:
вставляй прокладки для защиты от блокировок

Какие ограничения накладывает отсутствие "Счетчик_для_переключения_State"?
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Цитата
Старатель написал:
Какие ограничения накладывает отсутствие "Счетчик_для_переключения_State"?
     Никакие.  Пользователь анализирует свой код на наличие длинных участков на «чистом» Lua и в «нужных?» местах вставляет вызов какой-нибудь C-функции для переключения_State (с целью исключения блокировки запуска колбенов для других своих скриптов, если они у него есть ( QUIK это позволяет делать)).
---
   Но точно также можно задать похожий вопрос: какие ограничение наложило бы отсутствие в QUIK языка QLua?
   И вот возможный ответ; никакие, все можно написать на  ассемблере.
 
Цитата
Старатель написал:
Какие ограничения накладывает отсутствие "Счетчик_для_переключения_State"?
  Некоторое уточнение моих представлений относительно ценности любых средств разработки программ (в том числе QLua).
   Я уже в одном из своих комментариев отмечал:
  что когда обсуждаются любые средства разработки программ, вопрос «нельзя ли это сделать по-другому?» бессмысленен, по той причине, что все можно сделать по-другому. Вопрос по существу может быть таким: «упрощают ли предлагаемые средства разработки программ жизнь пользователя или нет? И в какой степени?».
 
Цитата
TGB написал:
Вопрос по существу может быть таким: «упрощают ли предлагаемые средства разработки программ жизнь пользователя или нет? И в какой степени?».

По моему мнению все "нововведения", которые удаляют или затрудняют работу текущего функционала, только ухудшают "жизнь пользователя".
https://forum.quik.ru/messages/forum10/message40996/topic4921
https://forum.quik.ru/messages/forum13/message40352/topic4830
Кому-то захотелось так сделать, потому что он посчитал, что ему лично так будет удобно. Программисты выполнили его хотелку, и в результате ухудшили жизнь другим.
Если что-то радикально менять, то это должен быть опциональный вариант.
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Цитата
Старатель написал:
По моему мнению все "нововведения", которые удаляют или затрудняют работу текущего функционала, только ухудшают "жизнь пользователя".
 Блокировку потоков длинным участком кода пользователя на "чистом" Lua, наверное, трудно назвать функционалом QLua.
 
Цитата
Старатель написал:
Если что-то радикально менять, то это должен быть опциональный вариант.
    Относительно обсуждаемой с вами блокировки потоков:
1. Вы для устранения существующей ошибки QLua предложили хороший вариант нейтрализации этой ошибки на уровне разработчика скриптов (все же, требующий нетривиального анализа и, возможно, дополнительного изменения кода скрипта при каждой его редакции).
2. Есть простая возможность (конкретные изменения в код Qlua, вносимые в течении 30 минут) с использованием идеи вашего предложения, устранить обсуждаемую ошибку в QLua таким образом, что от разработчики скриптов вообще освобождаются от борьбы с обсуждаемой ошибкой. Кроме того, семантика выполнения потоков в QLua становится стандартной (выполнение любого потока, само по себе, не блокирует выполнение других).
3. Мне непонятно, если оставаться в рамках профессионального обсуждения возможных решений, почему вы «топите» за то, чтобы ошибка не исправлялась?
 
Цитата
TGB написал:
вариант нейтрализации этой ошибки на уровне разработчика скриптов (все же, требующий нетривиального анализа и, возможно, дополнительного изменения кода скрипта при каждой его редакции)
Часто ли вам требовалось использовать этот вариант?

Цитата
TGB написал:
почему вы «топите»
Цитата
Старатель написал:
Это позволяет скриптеру писать байткод-циклы (в текущей версии QLua 5.3/5.4), выполняющиеся атомарно (читай потокобезопасно).
При реализации вашего пожелания на уровне QLua скриптер лишится такой возможности.

Я не против, если скриптер будет иметь контроль, например заданием переменной из скрипта: если счетчик задан, то снимать лок, через заданное количество циклов. Если не задан, то - без изменений. Как то так.
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
TGB,  вы предлагаете создать форк луа и встроить в квик именно форк. Это дорога в ад. Надеюсь, в арке это понимают.
 
Цитата
Anton написал:
TGB ,  вы предлагаете создать форк луа и встроить в квик именно форк. Это дорога в ад. Надеюсь, в арке это понимают.
  Мне кажется, с предупреждением, вы опоздали (как всегда, "все украли до нас" :smile: ).
 ARQA уже создала и использует форк луа:
  1) исходники Lua были изменены для обеспечения многопотоковости QLua (смотрите мой комментарий https://forum.quik.ru/messages/forum10/message54696/topic6356/#message54696);
  2) сравните размер кода Lua (~300 кб) с размером кода QLua (более 500 кб).
 
Цитата
TGB написал:
исходники Lua были изменены
Не смотрел в 8.13.1, но до этой версии могу смело утверждать, что луа был самый что ни на есть кондовый, все добавления аркой вносились только через интерфейсные макросы, специально для этого и предназначенные. Размер бинарника зависит от многих факторов. Естественно, определенные довески в коде есть, но именно что добавления, а не изменения.

Цитата
TGB написал:
смотрите мой комментарий
Там вы как раз неправильно делаете правильные вещи ) То же самое достигается без изменения кода луа.
 
1.
Цитата
Anton написал:
Там вы как раз неправильно делаете правильные вещи ) То же самое достигается без изменения кода луа.
  То, что я предложил очень конкретно, работает (прочитайте эту ветку сначала).
Где ваше предложение достичь того же самого без изменения кода Lua?

2. Здесь, как я понимаю, мы с вами обсуждаем конкретное предложение, протестированное  на моем стенде:
Цитата
TGB написал:
Прошло два месяца. Просьба к поддержки: сообщить результаты рассмотрения пожеланий.
 ----  
  Второе пожелание факультатив и, наверное, его стоит рассматривать после устранения критических ошибок, но первое пожелание (было отмечено сразу при описании пожеланий) это устранение ошибки.   Напоминаю:   Бывают ситуации зависания в QLua, когда основной поток обслуживания колбеков всех скриптов пользователя, а также таблиц QUIK (это не таблицы Lua), блокируется выполнением  длинного цикла пользовательской программы на «чистом» Lua, в котором нет ни вызова seep ни вызова других C-функций.  Это может порождать ошибки, которые для многих пользователей QLua (использующих несколько запускаемых скриптов)  являются неожиданными и труднообъяснимыми. Блокируются выполнения колбеков всех скриптов из-за выполнения длинного цикла пользовательской программы на «чистом» Lua в каком-то из запущенных пользователем скриптов.
-----
   Есть простой вариант реализации первого пожелания, кстати, совместимого со вторым  (далее список изменений реализующих этот вариант в в тексте исходни-ков Lua ):
1. В файле   lstate.h  после строки:  lu_byte allowhook;добавить: int Счетчик_для_переключения_State;
2. В файле   lstate.с  после строки:  L->errfunc = 0;добавить:  L->Счетчик_для_переключения_State = 0;
3. В файле   lstate.с  после строки:  L1->stacksize = BASIC_STACK_SIZE;добавить:  L1->Счетчик_для_переключения_State = 0;
4. В файле   lvm.с  после строки:  StkId ra;добавить:  
  if (++L->Счетчик_для_переключения_State > 1000) {   //  1000  надо задать кон-стантой  
     L->Счетчик_для_переключения_State = 0; lua_unlock(L); lua_lock(L);
  }
------------------------------------  
В чем проблема реализации первого пожелания?
  Вместо того, чтобы сделать конкретные замечания по выше предложенному, вы пускаетесь в филосовские рассуждения о том, после какой, внесенной в исходники Lua запятой, считать его «форк луа».  
   Причем, напомню вам, что по вашему же предложению (кстати, поддержанного в комментариях мною) были внесены разработчиком QUIK заметные изменения в обработку исключительных ситуаций Lua.  Наверное, вы ответите, что изменения в обработку исключений не делают Lua «форком луа» :smile: .
 
Цитата
TGB написал:
были внесены разработчиком QUIK заметные изменения
Посмотрите еще раз в той ветке, там все изменения в луа находятся в файле config.h и включают только (пере)определение предназначенных для кастомизации макросов и необходимые forward declarations. Поэтому да, я наверное скажу, что форком то предложение не являлось. Это кастомизация штатными средствами луа.

Цитата
TGB написал:
Где ваше предложение достичь того же самого без изменения кода Lua?
Того же самого я не хочу достигать, бо не вижу проблемы в существующем поведении и, более того, считаю такое поведение весьма удачным, случайно оно возникло или намеренно.
 
Цитата
Anton написал:
Того же самого я не хочу достигать, бо не вижу проблемы в существующем поведении и, более того, считаю такое поведение весьма удачным, случайно оно возникло или намеренно.
То есть, вы вполне удовлетворены тем, что QLua является «форком луа» (если вы отвергаете все остальное, приведенное мною в обоснование того, что QLua, похоже, форк ) хотя бы по причине:
Цитата
TGB написал:
1) исходники Lua были изменены для обеспечения многопотоковости QLua (смотрите мой комментарий  https://forum.quik.ru/messages/forum10/message54696/topic6356/#message54696) ;
И тогда что это:
Цитата
Anton написал:
вы предлагаете создать форк луа и встроить в квик именно форк. Это дорога в ад. Надеюсь, в арке это понимают.
 
TGB,  я не понимаю, чего вы от меня хотите. Вам стало скучно, вы придумали какую-то околесицу и пытаетесь ее всем навязать. Мне не нужны случайные переключения контекста посреди байткода. Мне они помешают. Я против вашего предложения. И многие будут против, когда на практике увидят, что из этого получится. Надеюсь не увидят. А форк или не форк мне не интересно.
 
Цитата
Anton написал:
А форк или не форк мне не интересно.
 Ну, не я же начал про  форки.  А ответил потому, что подумал, что, вдруг, узнаю что-то новое.

Цитата
Anton написал:
Вам стало скучно, вы придумали какую-то околесицу и пытаетесь ее всем навязать.
Насчет околесицы не согласен, почитайте наше с вами общение, начиная с комментария: https://forum.quik.ru/messages/forum10/message54757/topic6356/#message54757

Цитата
Anton написал:
Мне не нужны случайные переключения контекста посреди байткода. Мне они помешают.
  Это уже интересно.
Опишите как такие переключения вам мешают. Мне они никак не мешаю.
 
Цитата
TGB написал:
Опишите как такие переключения вам мешают.
Было уже написано в этой самой теме не мной. И другие подобные сценарии. Многие вещи, которые в 5.1 требовали длл и никак иначе, теперь можно сделать в скрипте. Вы это хотите сломать. Это уже достаточный аргумент, чтобы не поддержать идею. Можно и в обратную сторону спросить - а что это всем даст? Как скриптер от этого выиграет? Или хотя бы пример делающего что-то полезное кода без сишных вызовов, который иначе ну никак нельзя написать.
 
Цитата
Anton написал:
Было уже написано  в этой самой теме не мной. И другие подобные сценарии. Многие вещи, которые в 5.1 требовали длл и никак иначе, теперь можно сделать в скрипте. Вы это хотите сломать. Это уже достаточный аргумент, чтобы не поддержать идею. Можно и в обратную сторону спросить - а что это всем даст? Как скриптер от этого выиграет? Или хотя бы пример делающего что-то полезное кода без сишных вызовов, который иначе ну никак нельзя написать.
  Все, что вы написали (включая ссылку) как-то декларативно и нет конкретики. Типа, это не надо делать, потому что не надо.
 Но в вашем комментарии есть фразы, на которые я попытаюсь ответить или задать вопросы.
1.  Каким образом что-то будет ломаться, если будут переключение потоков внутри «чистого» кода Lua (байт-кода)?
---
 Сейчас переключение потоков в QLua возможно, и выполняется при вызове в скрипте C-функций, которых в рабочем скрипте обычно достаточно много (начиная со sleep). И при этом ничего не ломается.
  Что изменится в описанном выше качественно, если будут переключения на участках байт-кода? Ничего!  Вы же можете, без проблем, в существующий скрипт добавить, для своих целей, новые вызовы C-функций внутрь существующего байт-кода и это нормально.
 Предлагаемый мною вариант переключения внутри байт-кода это, по сути, добавление очень эффективного вызова «пустой», ничего не делающей C-функции через определенный интервал выполнения команд байт-кода. Это обеспечивает возможность переключения потоков внутри байт-кода и устранение блокировки потоков длительными фрагментами байт-кода.
  Интервал вызова «пустой» C-функции может быть таким (например, 1000), что дополнительные «окна» переключения потоков  практически никак не влияют на скорость выполнения скрипта (это проверено мною экспериментально). При этом разработчику скрипта. дополнительно к тому, чем занимается его скрипт, ничего делать не надо.

2.  Что это даст всем (скриптерам)?
 Сейчас, если в скрипте выполняется  длительный участок байт-кода main,  то на время его выполнения, блокируется выполнение основного потока, обрабатывающего колбеки всех запущенных скриптов пользователя и обслуживающего события таблиц QUIK. Все аналогично, если описанное выше, происходит в функции, вызванной в колбеке.
 -----
Для демонстрации выигрыша скриптера от реализации обсуждаемого предложения рассмотрим, например, следующую ситуацию.
У пользователя запущено два скрипта (почему бы нет, они будут выполняться в разных потоках):
первый скрипт продуктив, который реально торгует на рынке (обрабатывает колбеки);
второй скрипт продуктив, который тоже реально торгует на рынке (обрабатывает колбеки).
  Если во втором/первом скрипте в какой-то момент времени  будет обрабатываться длинный байт-код в main и при этом в нем вызовется колбек, то поток обработки колбеков всех скриптов будет заблокирован. При этом перестанут обслуживаться и колбеки первого/второго скрипта. Это может произойти неожиданно и в самом неподходящем месте и породить неприятные последствия для торгующего. Этого ожидает пользователь? Надо ли скриптеру, при каждой редакции своих скриптов анализировать свой код на возможность возникновения описанной ситуации или других похожих?
----
 Если бы было реализовано то, что я предлагаю, то описанных выше блокировок не было бы.
 Кто-то скажет, что описанный выше пример надуманный, редкий и так далее. Но, те, кто разрабатывал более-менее серьезные программы, наверное, понимают, что если есть баг в программе, то рано или поздно он может проявиться.
3. И вопрос Антону: все-таки, интересно, какую конкретную функциональность в своих разработках вы реализуете, использую блокировку потоков выполнением длинных участков байт-кода?
 
Цитата
TGB написал:
Если во втором/первом скрипте в какой-то момент времени  будет обрабатываться длинный байт-код в main
Вот я и просил показать пример такого байткода. Потому что байткод-в-себе, дрызгающий на одном месте без обращения к чему-то извне, это нонсенс. Модельку такую можно сделать, а как в реальной жизни к такому коду можно прийти, я прошу продемонстрировать.

Цитата
TGB написал:
какую конкретную функциональность в своих разработках вы реализуете, использую блокировку потоков выполнением длинных участков байт-кода?
Какие блокировки длинным кодом? Где про это говорилось-то? Смотрите:
Код
function OnStop()
   local t = tid
   tid = nil
   if t then
      DestroyTable(t)
   end
   run = false
end
Видите? Я табличку атомарно спрятал в локальную переменную и спокойно удалил. Когда DestroyTable снимает лок, мейн видит вместо таблички нил и все правильно понимает. После вашего улучшения такое без критической секции не сделаешь, а их в луа нет, если помните. Придется ради вот этой фигни извращаться. И так на каждой строчке.
 
Цитата
Anton написал:
Модельку такую можно сделать, а как в реальной жизни к такому коду можно прийти, я прошу продемонстрировать.
  Пусть это и демонстрирует реальная жизнь :smile:

Цитата
Anton написал:
Видите? Я табличку атомарно спрятал в локальную переменную и спокойно удалил. Когда DestroyTable снимает лок, мейн видит вместо таблички нил и все правильно понимает.
Точно также, если переключение (! оно не может возникать внутри команд Lua-машины, а только между ними) в байт-коде вдруг возникнет после tid = nil, но до DestroyTable, то оно снимает лок, мейн видит вместо таблички нил и все правильно понимает. При этом исполнение кода в мейн не сможет блокировать поток обработки колбеков и DestroyTable тоже успешно выполнится. В чем вы видите проблемы?

Цитата
Anton написал:
После вашего улучшения такое без критической секции не сделаешь, а их в луа нет, если помните. Придется ради вот этой фигни извращаться. И так на каждой строчке.
 Я помню, что в Qlua есть потокобезопасные функции, обеспечивающие функциональность критической секции и нет проблем использовать их в представленном вами примере (вы с этим сами можете разобраться и я не буду тратить время на то, как это можно сделать), Я только не очень понимаю зачем это может потребоваться в приведенном вами примере?
 Но дело обстоит еще проще. Если вы знакомы с документом разработчика QUIK «Использование Lua в Рабочем месте QUIK.pdf», то его в разделе «2. Взаимодействие потоков Lua скрипта» описана рекомендуемая схема обработки колбеков фондового рынка, которую можно распространить и на обработку колбеков событий таблиц QUIK. Если придерживаться этой схемы, то проблем многопоточности (! из-за основного потока обработки колбеков) в скрипте пользователя не будет вообще: ни в «чистом» Lua-коде ни в смешанном. И не надо ни чем извращаться ни в одной строчке скрипта так как при этом он становится однопоточным (относительно основного потока обработки колбеков). Вы можете почитать комментарии, начиная с https://forum.quik.ru/messages/forum10/message56387/topic6356/#message56387 , в которых это обсуждается с демонстрацией кодов, рекомендуемых разработчикам QUIK.
  Если же в скрипте не используется схема обработки колбеков, рекомендованная разработчиком QUIK, то преобразование любого такого скрипта в функционально эквивалентный, но с рекомендованной схемой, элементарное.
 
Цитата
TGB написал:
В чем вы видите проблемы?
Представьте, что во втором потоке выполняется та же самая функция. Первый поток выполняет local t = tid, переключается поток, второй поток выполняет local t = tid. Теперь без разницы, в каком порядке потоки выполняются дальше, они оба видят t != nil и оба вызывают DestroyTable, один из них - на уже убитой таблице. И это мы смотрим на простейший пример, где ничего страшного не произойдет. А на других примерах - произойдет. Это типичнейший паттерн вообще-то, как тут можно НЕ увидеть проблем...


Цитата
TGB написал:
в Qlua есть потокобезопасные функции, обеспечивающие функциональность критической секции
Об чем и речь, весь код У ВСЕХ будет в этих костылях просто потому, что вам кровь из носу хотелось чонить в квике починить, пусть даже и не сломанное.
 
Цитата
Anton написал:
А на других примерах - произойдет. Это типичнейший паттерн вообще-то, как тут можно НЕ увидеть проблем...
 Похоже, примеры с вами можно бы было обсуждать бесконечно  :smile:
----
Цитата
Anton написал:
Об чем и речь, весь код У ВСЕХ будет в этих костылях просто потому, что вам кровь из носу хотелось чонить в квике починить, пусть даже и не сломанное.
 Опять декларации и страшилки. Но это же можно бы было сформулировать короче: «Не тронь!» :smile:
Вы что, это не читали?:
Цитата
TGB написал:
дело обстоит еще проще. Если вы знакомы с документом разработчика QUIK «Использование Lua в Рабочем месте QUIK.pdf», то его в разделе «2. Взаимодействие потоков Lua скрипта» описана рекомендуемая схема обработки колбеков фондового рынка, которую можно распространить и на обработку колбеков событий таблиц QUIK. Если придерживаться этой схемы, то проблем многопоточности (! из-за основного потока обработки колбеков) в скрипте пользователя не будет вообще: ни в «чистом» Lua-коде ни в смешанном. И не надо ни чем извращаться ни в одной строчке скрипта так как при этом он становится однопоточным (относительно основного потока обработки колбеков). Вы можете почитать комментарии, начиная с  https://forum.quik.ru/messages/forum10/message56387/topic6356/#message56387  , в которых это обсуждается с демонстрацией кодов, рекомендуемых разработчикам QUIK.   Если же в скрипте не используется схема обработки колбеков, рекомендованная разработчиком QUIK, то преобразование любого такого скрипта в функционально эквивалентный, но с рекомендованной схемой, элементарное.
  или вы убежденный противник решения разработчика QUIK, приведенного в указанном фрагменте текста?
  Попытаюсь сформулировать, то, что написано там более понятно и короче.
  Если использовать то, что написано в этом фрагменте, то никакой синхронизации с потоком, обрабатывающем колбеки  не требуется. Ни нужны никакие костыли. Не требуется многочасовой анализ кода скрипта на атомарность/неатомарность, (ворк/неворк  :smile: ). Причем, это справедливо как для существующих версий QLua, так и в случае реализации предлагаемого мною решения, устраняющего ошибку блокировки потоков длинными участками байт-кода.
 Сформулировать это еще короче я уже, наверное, не смогу  :smile:
 
TGB,  этот марлезонский балет достал уже. Все показал, все на пальцах объяснил, теперь оказывается надо писать только так и никак иначе. Что воду в ступе толочь.
 
Цитата
Anton написал:
теперь оказывается надо писать только так и никак иначе
Если вы это так поняли, то, придется, все-таки стоит пояснить.
  Конечно же, каждый разработчик может писать скрипты как хочет:
1) постоянно, после очередной редакции скрипта, анализируя код на его атомарность/неатомарность (марлезонский балет);
2) не заморачиваясь проблемама синхронизации с колбеками (вообще не зная что такое атомарность)
И это никак не связано с тем, останется ли блокировка потоков участками байт-кода (как это про-исходит сейчас) или это будет устранено.

Цитата
Anton написал:
этот марлезонский балет достал уже
Согласен.
 
Цитата
TGB написал:
Конечно же, каждый разработчик может писать скрипты как хочет
, "но тем, кто будет писать не как я, подложу-ка я закладочку и выкручивайтесь как выйдет". Вот так вот получается.

Я хорошо понимаю, чего вы добиться хотите: возможности выполнять произвольный юзерский (то есть не контролируемый вами) код с возможностью его контролировать. Это невозможно в принципе, вы можете либо прибить зависший поток со всеми потрохами, либо ждать, когда он соизволит обратить на вас внимание. В то же время у нас есть виртуальная машина, поэтому арка может добавить отслеживание зависших скриптов, если вместо кондовой CRITICAL_SECTION в качестве лока будет использовать нечто иное с возможностью таймаута на вход. Если таймаут истек и секция не захвачена, весь скрипт убивается как в случае ошибки, все дела. В идеале сначала дергается некий юзерский колбек с вопросом "тебя прибить или сам отвиснешь", если ответил отвисну и не отвис, в морг. Вот что вам стоило бы попросить у арки, а не луа ломать.
 
Я уже думал, что наш диалог завершен, но вы пишите такие фантазийные, детективные тексты, что мне стало интересно.
Цитата
Anton написал:
но тем, кто будет писать не как я, подложу-ка я закладочку и выкручивайтесь как выйдет". Вот так вот получается.
 Где я такое написал?
Если вам кажется, что это находится в опубликованном мною коде, то укажите, где вы нашли такую закладку?

Цитата
Anton написал:
Я хорошо понимаю, чего вы добиться хотите
 Вы что, экстрасенс  :smile: ?
Я же просто представил протестированный на своем стенде (на котором в сое время тестировал исправление ошибки синхронизации QLua) код исправления блокировок потоков длинными участками байт-кода. Это короткие правки в 4-х местах кода QLua. Их можно изучать визуально, проверять экспериментально, искать в них "до посинения" закладки.

Цитата
Anton написал:
Это невозможно в принципе
 Вот и замечательно! Хорошо построенная программная система должна быть защищенной.

Цитата
Anton написал:
В то же время у нас есть виртуальная машина, поэтому арка может добавить отслеживание зависших скриптов, если вместо кондовой CRITICAL_SECTION в качестве лока будет использовать нечто иное с возможностью таймаута на вход. Если таймаут истек и секция не захвачена, весь скрипт убивается как в случае ошибки, все дела. В идеале сначала дергается некий юзерский колбек с вопросом "тебя прибить или сам отвиснешь", если ответил отвисну и не отвис, в морг. Вот что вам стоило бы попросить у арки, а не луа ломать.
 И это предлагается вместо "прозрачных" правок в 4-х места кода, вносимых туда в течении пяти минут? Как-то очень сложно (я бы до такого не додумался  :smile: ) и вот уж куда удобнее вставлять закладки.
 
Цитата
TGB написал:
я бы до такого не додумался
Есть вещи, друг горацио, что и не снились вашим мудрецам. Я писал сначала, что не надо луа патчить для решения вашей проблемы? Писал. Я написал, как решить ее без патча луа? Написал. Еще что-нибудь? Нагуглить для вас критическую секцию с таймаутом или сами сумеете?

Цитата
TGB написал:
закладки
Эко я хорошо слово подобрал. Все ж я экстрасенс, согласитесь.
 
Цитата
TGB написал:
  2) сравните размер кода Lua (~300 кб) с размером кода QLua (более 500 кб).

Вообще ни о чем не говорит.
Сильно зависит как от версии компилятора, от ключей компиляции, так и от режима линковки стандартной библиотеки.
 
Цитата
swerg написал:
Вообще ни о чем не говорит.
Я в начале 2021г. как-то сравнивал количество внешних функций Qlua и Lua. В Qlua их почти на сотню больше.
 
Anton , зачем вы все время требуете продолжение «марлезонского балета»?
Ну хорошо, продолжим.

Цитата
Anton написал:
Я писал сначала, что не надо луа патчить для решения вашей проблемы?
  На самом деле это проблема не моя. Для себя эту проблему я решил достаточно давно (аж в 2019г.,  когда разработал свою систему создания торговых роботов в QUIK). Утомлять вас здесь тем, как это у меня решено, я не буду.

Цитата
swerg написал:
Я написал, как решить ее без патча луа? Написал. Еще что-нибудь?
    Ну, наверное, вам бы стоило протестировать (на интервале, хотя бы, трех суток) предложенное вами решение у себя. И изложить его здесь с той же детальностью, как это сделал я.
 Наверное, из двух работающих решений можно бы выбрать то, которое лучше.
    Возможно, я бы и сам отказался от своего предложения. Я же не «упертый» и с дельными замечаниями, сделанными мне, легко соглашаюсь (можете посмотреть некоторые мои комментарии). А, кстати, почему вы так упорно боретесь против «форка lua»? Как то это сильно смахивает на борьбу за невинность девушки, которая уже больше года замужем.

Цитата
Anton написал:
Нагуглить для вас критическую секцию с таймаутом или сами сумеете?
Этого делать не надо, а лучше поищите закладки в моем коде  :smile: .
 
swerg, извиняюсь.  В моем предыдущем комментарии все цитата от Anton.
 
Что вы фигнёй маетесь, господа? Я вот тоже "разработал свою систему создания торговых роботов в QUIK", хотя появился здесь (и написал свою первую строчку на Lua) в сентябре прошлого года. Скрипт свой я уже и не помню, когда правил в последний раз. В ём сейчас 16 функций, включая main и прочие OnStop, объём кода менее 20 кило, и на все "версии компилятора, ключи компиляции и режимы линковки" мне давно пилювать с высокой колокольни. Кажется, при запуске скрипта Квик чо-то там компилирует - ну и пусть себе компилирует, а я скармливаю ему чистейший Lua как интерпретатору. Всё прекрасно работает! Сейчас я пишу совсем уж сумасшедший скрипт, уже не с трёхмерными, а с четырёхмерными массивами, с разветвлённым диалогом, и я уже совершенно точно знаю, что и он будет прекрасно работать - я просто не вижу, откуда могут появиться проблемы. Вернее, я пока пишу описание, то бишь набросок ТЗ, и пишу уже не первую неделю - задача АЛГОРИТМИЧЕСКИ сложная, а вот ТЕХНИЧЕСКИЕ вопросы решены уже сейчас. Ну, может, вылезет количество функций и/или объём кода за тридцатник - и чего? А может даже и не вылезет. Нафига вам это надо - не понимаю...

Нет, соврал - парочка нерешённых технических проблем ещё осталась:

1. Мне хотелось бы получать с сервера свечи (от 15-минутных и выше), при этом меня интересуют только последние две свечи по каждому таймфрейму, можно даже без коллбеков - только доступ к этим данным.

2. Я не умею программно прочесть состояние своего портфеля (та табличка, которая зелёненьким цвет текста выводит). Портфель я, ессно, веду у себя, но время от времени случаются сбои и рассогласование содержимого портфеля с точки зрения брокера и самого скрипта. Примерно раз в неделю я это дело проверяю (вручную) и убираю нестыковки. А хотелось бы делать это программно, примерно раз в полчаса. Никто не знает, как это сделать?
 
Цитата
TGB написал:
Скрипт свой я уже и не помню
 Я тоже свою систему почти не помню.
  Но вы же? в свое время? "нахлебались", по "полной", на таблицах QUIK (или нет). Вы что, хотите, чтобы и остальные пользователи получили "свое"?
  То, что вы просите, можно сделать самому. Вы, ведь, системный программист?
Мне, просто бывает интересно (когда есть время), как "кипит" "социальный бульон" в текущее время.
 
Опять цитата не моя, а Владимира, Извиняюсь перед собой :smile:
 
TGB, Дык я же давал чуть не десяток предложений в одном флаконе, и чуть ли не все они были зарегистрированы.  :smile:

ЧТО ИМЕННО "можно сделать самому"? Всё, что можно - я сделал: и свечи считаю сам, и портфель веду сам. Но тяжёлые свечи я хотел бы получать именно от сервера, и состояние моего портфеля именно от брокера. Что здесь "можно сделать самому"?

Системный-то я системный, но здесь же полностью прикладная задача. :smile:  
 
Цитата
Владимир написал:
TGB , Дык я же давал чуть не десяток предложений в одном флаконе, и чуть ли не все они были зарегистрированы.
  Вы за то, чтобы поток генерации колбеков блокировался фрагментами байт-кода?
  У вас есть конкретные замечания и возражения против моего конкретного протестированного предложения по устранению этих блокировок?
  Вы за то. чтобы был реализовано гипотетическое, "лабударно-завиральное", никак не проверенное предложение Anton, выдвинутое, как мне, но возможно ошибочно, кажется только для дискредитации того, что уже протестировано?
 
Цитата
Владимир написал:
Что вы фигнёй маетесь, господа? Я вот тоже "разработал свою систему создания торговых роботов в QUIK", хотя появился здесь (и написал свою первую строчку на Lua) в сентябре прошлого года. Скрипт свой я уже и не помню, когда правил в последний раз. В ём сейчас 16 функций, включая main и прочие OnStop, объём кода менее 20 кило, и на все "версии компилятора, ключи компиляции и режимы линковки" мне давно пилювать с высокой колокольни. Кажется, при запуске скрипта Квик чо-то там компилирует - ну и пусть себе компилирует, а я скармливаю ему чистейший Lua как интерпретатору. Всё прекрасно работает! Сейчас я пишу совсем уж сумасшедший скрипт, уже не с трёхмерными, а с четырёхмерными массивами, с разветвлённым диалогом, и я уже совершенно точно знаю, что и он будет прекрасно работать - я просто не вижу, откуда могут появиться проблемы. Вернее, я пока пишу описание, то бишь набросок ТЗ, и пишу уже не первую неделю - задача АЛГОРИТМИЧЕСКИ сложная, а вот ТЕХНИЧЕСКИЕ вопросы решены уже сейчас. Ну, может, вылезет количество функций и/или объём кода за тридцатник - и чего? А может даже и не вылезет. Нафига вам это надо - не понимаю...

Нет, соврал - парочка нерешённых технических проблем ещё осталась:

1. Мне хотелось бы получать с сервера свечи (от 15-минутных и выше), при этом меня интересуют только последние две свечи по каждому таймфрейму, можно даже без коллбеков - только доступ к этим данным.

2. Я не умею программно прочесть состояние своего портфеля (та табличка, которая зелёненьким цвет текста выводит). Портфель я, ессно, веду у себя, но время от времени случаются сбои и рассогласование содержимого портфеля с точки зрения брокера и самого скрипта. Примерно раз в неделю я это дело проверяю (вручную) и убираю нестыковки. А хотелось бы делать это программно, примерно раз в полчаса. Никто не знает, как это сделать?
"- Всё хорошо, прекрасная маркиза,
Дела идут и жизнь легка.
Ни одного печального сюрприза
За исключением пустяка.
Так, ерунда, пустое дело --
Кобыла ваша околела.
А в остальном, прекрасная маркиза,
Всё хорошо, всё хорошо."
Страницы: Пред. 1 2 3 4 След.
Читают тему (гостей: 1)
Наверх