Кривые шибки в QLua

Страницы: Пред. 1 2 3 4 5 6 След.
RSS
Кривые шибки в QLua
 
Цитата
TGB написал:
Цитата
Старатель написал:
код в сообщении  #24  в частности.
       Выполненные мною в Lua 5.3 (5.4) тесты атомарности операций вставки/удаления полей в таблицу показали, что эти операции (в условиях реализован-ной многопоточности QLua) все-таки атомарны.  Возможно?, есть ситуации, не охваченные тестированием, когда атомарности может не быть. Если же таких ситуаций нет, то мое утверждение, что выложенный Старателем код Queue (с описанием редко возникающей ошибки) создает потокоопасные очереди, ошибочное.
TGB, прекратите фантазировать.

этот код (усложненный) работает в сотнях (может тысячах, я не знаю) копий роботов, из числа выложенных  на сайте и написанных под заказ.
www.bot4sale.ru

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
Цитата
s_mike@rambler.ru написал:
этот код (усложненный) работает в сотнях (может тысячах, я не знаю) копий роботов, из числа выложенных  на сайте и написанных под заказ.
 Я же написал, что, похоже, что код потокобезопасный.
 Но если вам все известно, то объясните, что происходит время от времени в коде Старателя?
 
Цитата
s_mike@rambler.ru написал:
TGB, прекратите фантазировать.этот код (усложненный) работает в сотнях (может тысячах, я не знаю) копий роботов, из числа выложенных  на сайте и написанных под заказ.
   Вы что, никогда не сталкивались с ситуацией, когда программы использовались сотнями тысячами пользователями и в этих программах потом обнаруживались ошибки?
 
Цитата
TGB написал:
Цитата
s_mike@rambler.ru написал:
TGB, прекратите фантазировать.этот код (усложненный) работает в сотнях (может тысячах, я не знаю) копий роботов, из числа выложенных  на сайте и написанных под заказ.
    Вы что, никогда не сталкивались с ситуацией, когда программы использовались сотнями тысячами пользователями и в этих программах потом обнаруживались ошибки?
и спамить тоже прекращайте.
www.bot4sale.ru

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
Цитата
s_mike@rambler.ru написал:
и спамить тоже прекращайте.
 
Цитата
s_mike@rambler.ru написал:
и спамить тоже прекращайте.
  Это, конечно, аргумент :smile:  Особенно с учетом того, что вы мне не начальник.
 
Цитата
Старатель написал:
и код в сообщении  #24  в частности.
  Ответьте, пожалуйста, есть ли в этом коде вызов стандартных функций? Если есть, то какие и как часто?
 
Цитата
TGB написал:
Цитата
Старатель написал:
TGB ,   https://forum.quik.ru/messages/forum10/message57185/topic5823/#message57185  Это ваше сообщение?
Это мое сообщение, но
Цитата
TGB написал:
мы же обсуждаем код Queue_safe
Нет. Я ответил вам на результаты вашего теста.

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

  --- Функции работы с очередями (написаны на "чистом" Lua без обращения к C-функциям)  ---
    local new  =   function  ()
        return  {first  =   1 , last  =   0 }
     end 
    ---
    local push  =   function  (self, v)
        local  last  =  self.last  +  1 
        self[last]  =  v
        self.last  =  last
        return  last
     end 
    ---
    local pop  =   function  (self)
       local  first  =  self.first
       if  first  >  self.last  then   return   nil   end 
       local  v  =  self [first]
       self.first  =  first + 1 
       self[first]  =   nil 
       return  v, first
     end 
    ---
    local size  =   function  (self)
        return  self.last  -  self.first  + 1 
     end 
-----
--------- Создание очереди------
local  Queue_QUIK = new()
---------------------------------------

---  Основной поток обработки колбеков "обходит", запушенные на выполнение скрипты, с тем чтобы по событиям запускать их колбеки.
--  При этом должна быть обеспечена корректная синхронизация выполнения байт-кода колбека таким образом, что он не может выполняеться 
--  параллельно с байт-кодом потока main.
----------------------
local for_OnParam = 2 -- Множитель количества записей в очередь ----
local N_OnParam = 0
--- OnParam написана на "чистом" Lua без обращения к C-функциям  ---
function OnParam(p1, p2)
    for i = 1, for_OnParam do 
      N_OnParam = N_OnParam + 1
      -- Зпаись события  ---
      push (Queue_QUIK, {'OnParam', N_OnParam, {p1, p2}})   --  1. здесь создаются таблицы и может быть запущена автоматическая сборка мусора, 
                                                                                            --     которая работает для всей инсталяции Lua и не является потокобезопасной ---                                                                              
   end 
end
   
 ----   Обработка событий QUIK  (написана на "чистом" Lua без обращения к C-функциям) ----      
local function handle_events()   
      ----- ####  Для отладки ---
   local OnParam_begin = N_OnParam   
   local size_Queue_QUIK = size(Queue_QUIK)
   ---------------------------------
   ---  Чтение очереди событий -----
   local ms, first_q = pop (Queue_QUIK) 
      
    while ( ms  )   do        --- Есть события --- 
       -------------------------------
        ---  Чтение очереди событий -----      
        ms, first_q = pop (Queue_QUIK)  --Queue_QUIK: pop()         
   end
    ---   
    for i = 1, 1000 do      end  ---- нагрузка   ####  Отладка ---
   
    if N_OnParam ~= OnParam_begin then   --  Счетчик N_OnParam может иpмениться только в OnParam  
                                                              --  А это означает, что одновременно (параллельно) работают поток main и основной 
                         --  поток обработки колбеков, что недопустимо.
   --- это C-функция, но она вызывается только если  N_OnParam ~= OnParam_begin 
         message ( ' Параллельное выполнение колбека и потока main:  N_OnParam - OnParam_begin = ' .. tostring(N_OnParam - OnParam_begin)
                        .. '    size_Queue_QUIK = ' .. tostring(size_Queue_QUIK) )
    end      
    ----
end      
--------------------------------------------------------------------------------------------------------------------
--------
IsRun = true
function main()
    -------------------
    while IsRun do 
        handle_events()  ----   функция чтения событий OnParam ---
        sleep(2)  
    end
  ------------------
end   
   
function OnStop()
     IsRun = false
    return 10000   
end
 
Я не очень понимаю в чем могут быть проблемы запуска колбеков QLua.
 Вот вариант как это можно сделать просто ( C-API Lua):
Код
   if ( lua_getglobal (<Основной State в котором запускается колбек>, <Имя колбека>) == LUA_TFUNCTION)     // запись и проверка переменной колбека скрипта в стек
   { 
       if ( lua_pcall(<Основной State в котором запускается колбек>, <Количество параметров колбека>, <Список параметров колбека>)  ~= 0 )   // запуск колбека 
      {
          <Обработка ошибки при запуске колбека>
      }
    }
   else    //  в переменной колбека не функция
   {
        <Обработка ошибки пользователя, задавшего в качестве колбека не функцию>
   }


Этот вариант обеспечивает возможность (отсутствующую в существующей версии QLua) замены пользователем функции, вызываемой в качестве колбека, при исполнении скрипта.
 
Поддержка понимает, что пока не будут устранены "кривые, мерцающие, редкие" ошибки QLua, на нее будет постоянно валиться вал разнообразных ошибок из  различных функциональностей QLua?
   Если бы я был разработчиком QLua, то в первую очередь занимался бы устранением именно "кривых" ошибок. Это глобальные ошибки, которые могут проявляться у пользователя в любых местах его скриптов, вводя в заблуждения относительно источника ошибок.
 
TGB,  у меня для вас две новости, как водится:
1) в 5.3 воспроизводится буквально сразу, запущено 4 скрипта и заказаны все параметры по всем инструментам (на боевом);
2) в 5.4 в тех же условинях НЕ ВОСПРОИЗВОДИТСЯ.

Побочное:
1) колбеки так и запускаются, плюс-минус детали.
2) заменить колбек можно, если он был объявлен в виде хотя бы пустой функции. Если не был объявлен, квик его не будет дергать. Очень даже хорошая оптимизация, иначе квик бы на каждое событие разыскивал необъявленные функции во всех скриптах, что несколько затратно, учитывая локи.
 
Цитата
Anton написал:
в 5.3 воспроизводится буквально сразу, запущено 4 скрипта и заказаны все параметры по всем инструментам (на боевом);
 Все-таки, воспроизводится.
----
Цитата
Anton написал:
в 5.4 в тех же условинях НЕ ВОСПРОИЗВОДИТСЯ.
 Ну. тогда АРКИ надо объявить, что в версия QLua 5.3 не работоспособна.
---
Цитата
Anton написал:
колбеки так и запускаются, плюс-минус детали.
  Раскажите детали. Мне это было бы интересно.

 
Цитата
Anton написал:
Если не был объявлен, квик его не будет дергать. Очень даже хорошая оптимизация, иначе квик бы на каждое событие разыскивал необъявленные функции во всех скриптах, что несколько затратно, учитывая локи.
  Вы, наверное, знаете, что обращение lua_getglobal (<Основной State в котором запускается колбек>, <Имя колбека>) это эквивалентно обращение в тексте скрипта к переменной скрипта (тоесть. выполняется быстро). Это же обращение к полю таблицы. Или вы думаете, что это не так? Тогда подискутируем.
  А если это так, то о каком "разыскивании по всем скриптам" идет речь, когда происходит обращение к глобальной таблице, определяемой <Основной State в котором запускается колбек>.
  Вообще то, мне было бы интересно пообщаться с главным разработчиком QUIK. Но вы же, похоже не главный?
 
Цитата
TGB написал:
Раскажите детали.
Код
int callScriptOnAllTrade(lua_State * s)
{
   lua_checkstack(s, 1);
   int top = lua_gettop(s);
   lua_getglobal(s, "OnAllTrade");
   pushOnAllTradeArgument(s);
   int ret = doSafeLuaCall(s); // lua_pcall + SEH frame
   if(!ret)
      processScriptCallbackError(s);
   lua_settop(s, top);
   return ret;
}
Цитата
TGB написал:
Или вы думаете, что это не так?
Это lua_lock() + lua_getglobal() + lua_unlock(), совершенно бессмысленно это проделывать, точно зная, что в скрипте нет такой функции. Дискутировать лень.
Цитата
TGB написал:
Но вы же, похоже не главный?
Даже рядом не сидел.
 
Цитата
Anton написал:
lua_getglobal(s, "OnAllTrade");
  Что то, не  сильно, похоже на детали.  Например, не охватывается случай "OnParam".
А как вы обясните:
Цитата
Anton написал:
в 5.3 воспроизводится буквально сразу, запущено 4 скрипта и заказаны все параметры по всем инструментам (на боевом
----
Цитата
Anton написал:
Это lua_lock() + lua_getglobal() + lua_unlock(), совершенно бессмысленно это проделывать, точно зная, что в скрипте нет такой функции. Дискутировать лень.
 Ну, конечно, вместо lua_getglobal(...)  (кстати, lua_lock() и lua_unlock() выполняется внутри функции lua_getglobal), эквивалентной с точки зрения времени обращения, обращению к глобальной переменной, даже если этой переменной не существует, можно заняться более содержательным алгоритмом регистрации колбеков скриптов (где можно и ошибиться - замечательная возможность).
 
Цитата
TGB написал:
Например, не охватывается случай "OnParam".
Все такое же, имена поменяйте. Там может вообще темплейт в сорце.

Цитата
TGB написал:
А как вы обясните:
Никак на данный момент. Вижу, что все случаи показывают большой размер очереди, 200-400 элементов. Это значит, что у коллектора тоже достаточно большая очередь. Это значит, что коллектор начинает агрессивничать и влезать в любую доступную дыру. Где он там дыру в мейне нашел, науке пока неизвестно.

Цитата
TGB написал:
кстати, lua_lock() и lua_unlock() выполняется внутри функции lua_getglobal
Я кагбэ в курсе. Специально показал оверхед против просто обращения к таблице из байткода. Спорить мне все равно лень.
 
Цитата
Anton написал:
Все такое же, имена поменяйте. Там может вообще темплейт в сорце.
 Имена я способен поменять, но мы же обсуждаем не то что я могу сделать, а как это сделано в текущем QLua.
Цитата
Anton написал:
Это значит, что коллектор начинает агрессивничать и влезать в любую доступную дыру. Где он там дыру в мейне нашел, науке пока неизвестно.
В принципе, если обеспечено четкое разделение между потоками, среды исполнения Lua (то есть, она разделяемый ресурс с корректной синхронизацией доступа к ней) то это эквивалентно однопоточному Lua, в котором ошибки, конечно есть, но их мало.
 
Цитата
Anton написал:
TGB ,  у меня для вас две новости, как водится:
1) в 5.3 воспроизводится буквально сразу, запущено 4 скрипта и заказаны все параметры по всем инструментам (на боевом);
2) в 5.4 в тех же условинях НЕ ВОСПРОИЗВОДИТСЯ.
 Действительно, в Qlua 5.4 тест ошибку не диагностирует.
---
 Спасибо Антону за его уточнение.
--
А где поддержка?
 
Просьба (повторная) к поддержке: довести содержимое моего комментария: https://forum.quik.ru/messages/forum10/message57872/topic5823/#message57872 до разработчиков QUIK.
  В QUIK 9.2.1.4 (с последними обновлениями) тестовый скрипт, выложенный в упомянутом выше комментарии, демонстрирует, по моему мнению, ошибку в запусках колбеков, в QLua 5.3 ( в  QLua 5.4 эта ошибка не диагностируется, но это не означает, что в 5.4 такой ошибки нет).
 
Где реакция поддержки?
----
  Третий раз (первый комментарий был написан 10.09.2021 07:46:28  https://forum.quik.ru/messages/forum10/message57872/topic5823/#message57872) обращаю внимание поддержки на то, что тест, выложенный 10.09.2021 07:46:28  в данной ветке,  в QUIK (8.13.1.16, 9.1.3.11 и 9.2.1.4 (с последними обновлениями), в QLua 5.3 демонстрирует ошибку в запусках колбеков.  Это подтверждено пользователем Anton (смотрите комментарий 61).
  Если перевести на простой язык, то диагностируется ошибка синхронизации выполнения потока запуска колбеков и потока main скрипта (и это после полутора года эксплуатации новых версий QUIK :!: ). Ошибки синхронизации могут проявляться как случайные сбои в сриптах пользователей в различные моменты времени.
  Что из выше написанного не понятно?
  А если непонятно, то где вопросы?
 
Здравствуйте!

Ваше письмо получено, проблема изучается. Постараемся в ближайшее время дать ответ.
 
Цитата
s_mike@rambler.ru написал:
TGB, прекратите фантазировать.
 Хотелось бы увидеть ваш комментарий (с возможными возражениями), но конкретный, с указанием строк в выложенном мною тесте.
----
Цитата
Daniil Pozdnyakov написал:
Ваше письмо получено, проблема изучается. Постараемся в ближайшее время дать ответ.
 Спасибо. Буду ждать обновления QUIK и после этого запускать свой тест.
 
Цитата
Daniil Pozdnyakov написал:
Ваше письмо получено, проблема изучается. Постараемся в ближайшее время дать ответ.
    Здравствуйте!
    Появилась версия QUIK 9.2.2.11 (с обновлениями).   В этой версии в QLua 5.3 тест, описанный в комментарии (10.09.2021) https://forum.quik.ru/messages/forum10/message57872/topic5823/#message57872  демонстрирует ошибку в запусках колбеков. Эта ошибка может проявляться как случайные сбои в сриптах пользователей в различные моменты времени.  В версии в QLua 5.4 ошибка не проявляется
    У поддержки есть вопросы по тесту?
 
Добрый день,

Проблема, о которой Вы говорите, на данный момент изучается, и, к сожалению, какую-либо резолюцию, а также сроки решения данной задачи дать не можем.
 
Цитата
Daniil Pozdnyakov написал:
Проблема, о которой Вы говорите, на данный момент изучается, и, к сожалению, какую-либо резолюцию, а также сроки решения данной задачи дать не можем.
   Долго изучаете проблему.
 Не точно, но скорее всего, колбеки регистрируются в QLua (а этого можно и не делать - смотрите мои комментарии) с помощью функции: void luaL_setfuncs (lua_State *L, const luaL_Reg *l, int nup) и, наверное, с параметром nup = 0. Параметр nup = 0 означает, что это C - функции и они запускаются без блокировки байт-кодов. Что является ошибкой.
----
 Возможно, я ошибаюсь, и все-таки просьба к поддержке: донести этот комментарий до разработчиков QUIK.
 
Цитата
TGB написал:
Параметр nup = 0 означает, что это C - функции
Этот параметр указывает количество upvalues, прицепленных к каждой функции. Их можно и к сишным функциям прицепить. Соответственно причина явно не в этом. И таки нет, там все просто, lua_pushcfunction + lua_setglobal (возможно, в сорце это один вызов и компилятор его автоматом так разворачивает, тем не менее).
 
Цитата
Anton написал:
Этот параметр указывает количество upvalues, прицепленных к каждой функции. Их можно и к сишным функциям прицепить. Соответственно причина явно не в этом.
   Вообще, мне (и остальным пользователям QUIK) не интересны причины наблюдаемой ошибки. Нам существенно, чтобы эта ошибка была устранена.
 
TGB, Добрый день,
Цитата
TGB написал:
Не точно, но скорее всего, колбеки регистрируются в QLua (а этого можно и не делать - смотрите мои комментарии) с помощью функции: void luaL_setfuncs (lua_State *L, const luaL_Reg *l, int nup) и, наверное, с параметром nup = 0. Параметр nup = 0 означает, что это C - функции и они запускаются без блокировки байт-кодов. Что является ошибкой.----  Возможно, я ошибаюсь, и все-таки просьба к поддержке: донести этот комментарий до разработчиков QUIK.

спасибо за Ваш комментарий, он будет учтён при разборе.
 
Цитата
Anton написал:
Соответственно причина явно не в этом.
 Согласен.  luaL_setfuncs не применима к функциям Lua, а только к С-функциям.
---
 Эксперименты показали, что проблема в lua_pcall (нет блокировки доступа к байт-кодам). Либо в этой функции нет синхронизации в QLua 5.3 (что очень сомнительно), либо в ней не корректно указана ссылка на объект синхронизации (он должен быть общим для всех lua_State скрипта).
 
TGB,  если уж говорить о возможных причинах, я бы посмотрел на хайли лайкли происходящий рехэш таблицы при вставке. Проверить это при наличии сорцев просто, поставить бряк на рехэш и запустить ваш тест. А так "из общих соображений" можно весь луа перерыть.
 
Цитата
Daniil Pozdnyakov написал:
спасибо за Ваш комментарий, он будет учтён при разборе.

Тест, описанный в комментарии (10.09.2021) https://forum.quik.ru/messages/forum10/message57872/topic5823/#message57872  упростился (строка с проблемным кодом помечена символом ###):
Код
local for_OnParam = 2 -- Множитель 
local N_OnParam = 0
----
function OnParam(p1, p2)
    for i = 1, for_OnParam do 
      N_OnParam = N_OnParam + 1                                                                              
   end
end
---
--------
IsRun = true
function main()
    local J
    local OnParam_begin   
    -------------------
    while IsRun do 
     ------
     do
        OnParam_begin = N_OnParam   
             J = 100000000   
             while ( J > 0  )   do   J = J - 1  end      -- ### Проблема здесь.   "Чистый" байт-код, но в QLua 5.3 здесь переключаются потоки (! в 5.4 этого нет)---- 
--         for i = 1, 100000000 do  end        --  Это в QLua 5.3 работает нормально  ---

        if N_OnParam ~= OnParam_begin then   --  Счетчик N_OnParam может исмениться только в OnParam  
                message ( ' Переключение колбека и потока main:  N_OnParam - OnParam_begin = ' .. tostring(N_OnParam - OnParam_begin))
            end      
   end
   -----
       sleep(10)  
  end
  ------------------
end   
   
function OnStop()
     IsRun = false
    return 10000   
end
 
TGB,  нет квика под рукой, посмотрите плиз, вот так воспроизведется?
Код
local for_OnParam = 2
local N_OnParam = 0
IsRun = true

function OnParam(p1, p2)
   for i = 1, for_OnParam do 
      N_OnParam = N_OnParam + 1                                                                              
   end
end

function main()
   while IsRun do 
    do
      local OnParam_begin = N_OnParam   
      local J = 100000000   
      while ( J > 0  )   do   J = J - 1  end
      if N_OnParam ~= OnParam_begin then
         message ( ' Переключение колбека и потока main:  N_OnParam - OnParam_begin = ' .. tostring(N_OnParam - OnParam_begin))
      end      
   end
   sleep(10)  
   end
end   
   
function OnStop()
   IsRun = false
   return 10000   
end

 
Цитата
Anton написал:
нет квика под рукой, посмотрите плиз, вот так воспроизведется?

Да
 
Старатель, добрый день!
Цитата
Старатель написал:
Второй раз в 9.1:
Цитата
Старатель написал:
Код
   local  hour  =   0  +  os.date ( '%H' )  
 выскочила такая ошибка:
 
Цитата
attempt to perform arithmetic on a nil value
 
Цитата
stack traceback:
[C]: in metamethod 'add'

Также  ошибка
Цитата
attempt to call a nil value (method 'pop')
в 9.1 никуда не пропала.

Откуда здесь nil?

Извиняемся за задержку с ответом.
К сожалению, нам не удалось понять причину возникшей ошибки.
В случае повтора просьба максимально подробно описать обстоятельства возникновения ошибки.
Приносим извинения за причиненные неудобства.
 
Цитата
TGB написал:
Просьба (повторная) к поддержке: довести содержимое моего комментария:  https://forum.quik.ru/messages/forum10/message57872/topic5823/#message57872  до разработчиков QUIK.
  В QUIK 9.2.1.4 (с последними обновлениями) тестовый скрипт, выложенный в упомянутом выше комментарии, демонстрирует, по моему мнению, ошибку в запусках колбеков, в QLua 5.3 ( в  QLua 5.4 эта ошибка не диагностируется, но это не означает, что в 5.4 такой ошибки нет).
Добрый день.

Поведение Lua 5.4 считаем правильным, т.е. именно таким, каким было задумано её автором, и рекомендуем использовать именно её.
 
Цитата
Alexey Ivannikov написал:
Поведение Lua 5.4 считаем правильным, т.е. именно таким, каким было задумано её автором, и рекомендуем использовать именно её.
  Здравствуйте.
 Действительно, обсуждаемую ошибку в QLua 5.4 я не наблюдал. Но, если разработчик QUIK поддерживает и QLua 5.3, то, наверное, надо эту ошибку устранить и в QLua 5.3. Тем более, что эта ошибка базовой функциональности обработки колбеков.
  Причем, тест https://forum.quik.ru/messages/forum10/message58500/topic5823/#message58500 , диагностирующий ошибку мною упрощен до такой степени, что проявление ошибки в коде теста локализовано в пределах одной строки, помеченной комментарием --- ###.
 
Цитата
Anton написал:
local for_OnParam = 2 -- Множитель
local N_OnParam = 0
----
function OnParam(p1, p2)
   for i = 1, for_OnParam do
     N_OnParam = N_OnParam + 1                                                                              
  end
end
---
--------
IsRun = true
function main()
   local J
   local OnParam_begin  
   -------------------
   while IsRun do
    ------
    do
       OnParam_begin = N_OnParam  
            J = 100000000  
            while ( J > 0  )   do   J = J - 1  end      -- ### Проблема здесь.   "Чистый" байт-код, но в QLua 5.3 здесь переключаются потоки (! в 5.4 этого нет)----
--         for i = 1, 100000000 do  end        --  Это в QLua 5.3 работает нормально  ---

       if N_OnParam ~= OnParam_begin then   --  Счетчик N_OnParam может исмениться только в OnParam  
               message ( ' Переключение колбека и потока main:  N_OnParam - OnParam_begin = ' .. tostring(N_OnParam - OnParam_begin))
           end      
  end
  -----
      sleep(10)  
 end
 ------------------
end  
Вариант возможной ошибки.
----------------------
цикл  for i = 1, 100000000 do  end    - пустой. Оптимизирующий компилятор его просто выкинет.
----------------------
Переменная N_OnParam   меняется внутри колбека, т е внутри основного потока.
------------------
эта переменная определяет параметр  OnParam_begin   для  if сообщения в потоке main.
------------------------------
Проверка условия и смена параметра асинхронны.
-------------------------------
Т е в зависимости от активности на бирже и загрузке процессора условие может  не выполнятся никогда.
--------------------------
т е будем получать редкие глюки в зависимости от активности торговли и загрузки процессора.
Что собственно и наблюдается.
-------------------------
Все верно?


 
 
Цитата
nikolz написал:
цикл  for i = 1, 100000000 do  end    - пустой. Оптимизирующий компилятор его просто выкинет.
Разве что внешний какой-нибудь. Квиковский не выкидывает.

Цитата
nikolz написал:
условие может  не выполнятся никогда
Оно не должно выполниться никогда по логике переключения потоков в луа текущих версий. И в 5.4 не выполняется никогда, а в 5.3 выполняется. Вот об этом и разговор тут, мол поправить бы.

Код-то не мой скопировали. Я его менял, предположив, что поток переключается в момент создания замыкания, и занес локальные внутрь do-end, дабы проверить. Но не угадал. В общем случае в 5.3 замыкание может создаваться небезопасно, а в 5.4 этот кусок изменен, так что вполне вероятно, что ноги все-таки оттуда растут. Ковырять некогда.
 
Цитата
Anton написал:
В общем случае в 5.3 замыкание может создаваться небезопасно
 При корректной синхронизации (в тех местах кода Lua, определенных разработчиком Lua) в той схеме, которую определили разработчики Lua для использования ее во многих потоках, почему? Не понял. В этой схеме работа Lua эквивалентна ее однопоточному использованию. Я это проверял и пока ошибок у разработчиков Lua не обнаружил.
 
Цитата
TGB написал:
В этой схеме
   В предыдущем моем комментарии у меня не было времени подробно пояснить, что понимается под схемой использования Lua во многих потоках. Попробую это сделать сейчас.
   Главный thread  и остальные thread Lua пространственно, по стеку, разделены и поэтому могли бы обрабатываться в разных потоках без синхронизации. Но не допустима обработка любого thread в нескольких потоках. Если в разных thread нет общих модифицируемых данных, то синхронизация между thread не требовалась бы. Казалось бы, thread могли бы работать параллельно, синхронизируясь только на общих модифицируемых данных. Однако, в Lua есть «общее хозяйство» всех thread , требующее синхронизацию – это общая автоматическая память Lua, поддерживаемая мусорщиком, «заточенным» разработчиками Lua только на однопоточное использование. Поэтому VM-Lua можно использовать в разных потоках только в разделяемом режиме. В любой момент времени VM-Lua может обрабатывать только один поток.
 
Цитата
TGB написал:
почему? Не понял.
Смотрим, как замыкание создается в 5.3
Код
      vmcase(OP_CLOSURE) {
        Proto *p = cl->p->p[GETARG_Bx(i)];
        LClosure *ncl = getcached(p, cl->upvals, base);  /* cached closure */
        if (ncl == NULL)  /* no match? */
          pushclosure(L, p, cl->upvals, base, ra);  /* create a new one */
        else
          setclLvalue(L, ra, ncl);  /* push cashed closure */
        checkGC(L, ra + 1);
        vmbreak;
      }
оп, а там checkGC на главном пути
Код
#define checkGC(L,c)  \
        { luaC_condGC(L, L->top = (c),  /* limit of live values */ \
                         Protect(L->top = ci->top));  /* restore top */ \
           luai_threadyield(L); }
а там luai_threadyield тоже на главном
Код
#define luai_threadyield(L)     {lua_unlock(L); lua_lock(L);}
То есть даже не то что может быть небезопасно, как я по памяти написал, а всегда небезопасно. А в 5.4 это место по-другому сделано.

Для уверенности еще надо доказать, что в этом примере компилятор использовал OP_CLOSURE, а не что-то другое. Для этого надо скомпилировать (именно в квике) в файл и отреверсить результат. Мне некогда заняться.
 
Цитата
Anton написал:
А в 5.4 это место по-другому сделано.
Поправлюсь: по-другому, но тоже есть yield на главном пути. В общем, надо установить сначала, присутствует ли этот опкод в байткоде циклов в обеих версиях, иначе голое теоретизирование получается. Если окажется, что в 5.3 опкод есть, а в 5.4 нет, то задача решена. Если что-то другое окажется, то, глядя на байткод, можно будет просто ручками пройти по нему и посмотреть, что происходит, а не просто пытаться угадать.
 
Короче нет в циклах опкода OP_CLOSURE, дело не в этом. Слева 5.3.5, справа 5.4.1.

 
 
Цитата
Anton написал:
Смотрим, как замыкание создается в 5.3
  Я так и не понял, зачем вы анализировали замыкание функций в пустом цикле:
Код
J = 100000000   
 while ( J > 0  )   do   J = J - 1  end      -- ### Проблема здесь.   "Чистый" байт-код, но в QLua 5.3 здесь переключаются потоки (! в 5.4 этого нет) 

 Добавлю к приведенному выше коду:   и не должно быть при корректной реализации многопоточного использования Lua.
 
TGB,  еще точнее проблема здесь

Лок выпустить может только мейн, раз уж он его захватил. Никакие телодвижения со стороны главного потока квика его не выпустят. Отсюда варианта два:
1) главный поток квика где-то лезет в луа без захвата лока;
2) лок выпускается одним из опкодов на картинке. Например, JMP может вызывать luaF_close, а она luaM_free, а она может вызывать luaC_fullgc, если определен макрос HARDMEMTESTS. Поэтому первое, что б я сделал, это посмотрел на предмет наличия этого макроса в 5.3.
 
Цитата
Anton написал:
TGB ,  еще точнее проблема здесь
Согласен.
 
Цитата
Anton написал:
Никакие телодвижения со стороны главного потока квика его не выпустят.
А вот тут наврал. Таки можно выпустить из другого потока, проверил сейчас. Тксть на майкрософт надейся, а сам не плошай. Значит, есть третий вариант:
3) основной поток квика зачем-то выпускает лок, который не захватывал.
 
Цитата
Anton написал:
проблема здесь
 И пусть разбираются разработчики QUIK.
 
Цитата
TGB написал:
Цитата
Anton написал:
проблема здесь
  И пусть разбираются разработчики QUIK.
Добрый день.

Результат разбора был передан Вам в сообщении 84 (выше). Если Вы не согласны с данной резолюцией - просьба подробно описать почему, мы передадим эту информацию разработчикам.
 
Цитата
Alexey Ivannikov написал:
Добрый день.Результат разбора был передан Вам в сообщении 84 (выше). Если Вы не согласны с данной резолюцией - просьба подробно описать почему, мы передадим эту информацию разработчикам.
  Здравствуйте.
Действительно, обсуждаемую ошибку в QLua 5.4 я не наблюдал. Но, если разработчик QUIK поддерживает и QLua 5.3, то, наверное, надо эту ошибку устранить и в QLua 5.3. Тем более, что эта ошибка базовой функциональности обработки колбеков.
 Причем, тест https://forum.quik.ru/messages/forum10/message58500/topic5823/#message58500 , диагностирующий ошибку мною упрощен до такой степени, что проявление ошибки в коде теста локализовано в пределах одной строки, помеченной комментарием --- ###.  Этот тест разработчик может использовать при поиске ошибки в QLua. Просьба передать его коды и описание ошибки в комментарии https://forum.quik.ru/messages/forum10/message57872/topic5823/#message57872 разработчику QUIK.
 
Цитата
TGB написал:
Цитата
Alexey Ivannikov написал:
Добрый день.Результат разбора был передан Вам в сообщении 84 (выше). Если Вы не согласны с данной резолюцией - просьба подробно описать почему, мы передадим эту информацию разработчикам.
   Здравствуйте.
Действительно, обсуждаемую ошибку в QLua 5.4 я не наблюдал. Но, если разработчик QUIK поддерживает и QLua 5.3, то, наверное, надо эту ошибку устранить и в QLua 5.3. Тем более, что эта ошибка базовой функциональности обработки колбеков.
 Причем, тест  https://forum.quik.ru/messages/forum10/message58500/topic5823/#message58500  , диагностирующий ошибку мною упрощен до такой степени, что проявление ошибки в коде теста локализовано в пределах одной строки, помеченной комментарием --- ###.  Этот тест разработчик может использовать при поиске ошибки в QLua. Просьба передать его коды и описание ошибки в комментарии  https://forum.quik.ru/messages/forum10/message57872/topic5823/#message57872  разработчику QUIK.
Здравствуйте!

Информация получена, проблема изучается. Постараемся в ближайшее время дать ответ.
Страницы: Пред. 1 2 3 4 5 6 След.
Читают тему
Наверх