Новая версия терминала 8.13 для отладки должна была появиться в этой папке: ftp://ftp.quik.ru/public/updates/8.13/ но там на момент написания этого сообщения пусто. Не повезло 13-й версии, к сожалению.
У Квика, работающего через одного моего брокера, версия 8.8, через второго - 8.11, у моего друга - 8.10. Это не считая ещё пары цифирей после того. На форуме обсуждается 8.12, которая, по слухам, "страдает падучей" и работает хуже всех предыдущих, но нет предела совершенству!
Новые версии QUIK стали заметно устойчивее, чем это было в мае 2020г. Однако, нечасто, но в течении двух-трех суток версия QUIK 8.13, в которой запущен мой тест синхронизации в QLua, без подключения к серверу, зависает с выдачей сообщения: Critical error ACCESS_VIOLATION (Критическая ошибка НАРУШЕНИЕ ДОСТУПА). Дампы при этом не сбрасываются. Многое указывает на то, что в QUIK 8.13 есть ошибка синхронизации (и все-таки земля вертится ). Попробую это обосновать. 1. Ошибка «error ACCESS_VIOLATION» в QUIK 8.13 возникает в разных местах моей тестовой программы, и в разные моменты времени. 2. Я собрал из исходников Lua 5.3.5 вариант исполняемого кода Lua (свой стенд), в котором допустимы обращения к VM-Lua из разных потоков. На этом стенде, точно та же моя тестовая программа (16 интенсивно нагруженных потоков в одном Lua-скрипте), работает непрерывно неделями, и я не могу дождаться, когда же она, наконец, упадет. 3. Я провел следующий эксперимент: 1) Запустил на выполнение программу на «чистом» Lua (без обращения к С-кодам, где отсутствует синхронизация) в QUIK 8.13 и на моем стенде. Время выполнения оказалось одинаковым. 2) Запустил на выполнении программу на «смешанном» Lua (с обращениями к С-кодам, где должна работать синхронизация) в QUIK 8.13 и на моем стенде. Время выполнения оказалось разным. Причем на моем стенде ~ 1, 4 раза больше. Вопрос: в QUIK 8.13 сумели, как то сильно оптимизировать синхронизацию доступа к VM-Lua из разных потоков? Я думаю, это вряд ли. Скорее всего, есть ошибка в реализации синхронизации в QLua 8.13.
В своем стенде, для синхронизации доступа к VM-Lua, я использую критическую секцию, и далее я приведу все места в исходном тексте Lua 5.3.5, где мною были внесены изменения для обеспечения синхронизации. Обращаю ваше внимание на то, что при синхронизации должен использоваться общий объект синхронизации. Возможно?, место синхронизации в QLua было выбрано неудачно. ----- Мои изменения (для обеспечения синхронизации) в исходном коде Lua 5.3.5 приведены в следующем виде: 1) № изменения 2) <Имя файла исходника> 3) <Текст исходника, позволяющий определить место после которого внесено изменение> 4) <Текст изменения> -------------------------------------------------------------------------------- 1. Изменение № 1 Файл: ldo.c Место: #include "ldo.h" Добавление: #include "DbgHelp.h" #pragma comment(lib, "Dbghelp.lib") void lua_lock_MT(lua_State *L) { global_State *g = G(L); EnterCriticalSection(&g->Глобальная_критическая_секция); }
4. Изменение № 4 Файл: limits.h Место: /* ** macros that are executed whenever program enters the Lua core ** ('lua_lock') and leaves the core ('lua_unlock') */ Добавление: #if !defined(lua_lock) #define lua_lock(L) lua_lock_MT(L) #define lua_unlock(L) lua_unlock_MT(L) #endif ----- 5. Изменение № 5 Файл: luaconf.h Место: ** the libraries, you may want to use the following definition (define ** LUA_BUILD_AS_DLL to get it). */ Добавление: #define LUA_BUILD_AS_DLL ----- 6. Изменение № 6 Файл: lstate.c Место: g->gcstepmul = LUAI_GCMUL; Добавление: InitializeCriticalSection(&g->Глобальная_критическая_секция); ----- 6. Изменение № 7 Файл: lstate.h Место: TString *strcache[STRCACHE_N][STRCACHE_M]; /* cache for strings in API */ Добавление: CRITICAL_SECTION Глобальная_критическая_секция;
Евгений написал: Придется оправдаться за неисправленные ошибки, лучше не читать
)
Читать не читают, но что характерно : 1. Мой комментарий был написан 10.04.21. 2. А вчера вечером (13.04.21) мой QUIK 8.13.0.106 совершенно неожиданно для меня автоматически обновился. Возможно это простое совпадение, но на всякий случай я запустил в нем свой тест (с подключением к серверу. Если он не "обрушит" обновленную версию QUIK в течении недели (до 20.04.21) то, наверное, разработчиков QUIK можно будет поздравить. При этом я не исключаю, что действительно поддержка ветку не читает (и особенно, длинные тексты )
TGB,а как квик может обновиться "неожиданно для вас"? Появляется оповещение "На сервере появилась новая версия, обновить?" Если нажмёте кнопочку "нет" , то будете работать на старой версии.
Александр Волфовиц написал: TGB ,а как квик может обновиться "неожиданно для вас"? Появляется оповещение "На сервере появилась новая версия, обновить?" Если нажмёте кнопочку "нет" , то будете работать на старой версии.
"Неожиданно для меня" это фигура речи. Конечно же, мною были нажаты все необходимые кнопки.
TGB написал: Я собрал из исходников Lua 5.3.5 вариант исполняемого кода Lua (свой стенд)
Получился именно свой стенд, довольно далекий от того, как сделано в квике. Отсюда и проигрыш квику в скорости. Квик перехватывает создание стейта для скрипта (для этого в луа есть соответствующие макросы под переопределение), прицепляет к стейту дополнительную структуру и создает критическую секцию в этой структуре, свою для каждого скрипта (именно поэтому разные скрипты таки могут выполняться параллельно друг другу, у вас - нет). Макросы lua_lock/lua_unlock устроены сложнее, чем у вас, они получают из стейта указатель на эту дополнительную структуру и захватывают/выпускают критическую секцию, принадлежащую данному скрипту (а не одну общую, как у вас). Кстати, удаляется эта дополнительная структура весьма затейливым образом, поскольку при наивном подходе существует вероятность возникновения гонок. В частности, попытка захватить прибитую критическую секцию дает как раз наш любимый ACCESS VIOLATION. Совпадение? Не думаю! (но может быть и совпадение) Еще учтите, что в квике все эти макросы выбирают не только нужный скрипт, но и нужную версию луа, то есть они еще сложнее, чем я описал, вариантов "хотеть как лучше, а получить AV в продакшене" у программистов арки больше, чем хотелось бы.
Anton написал: Квик перехватывает создание стейта для скрипта (для этого в луа есть соответствующие макросы под переопределение), прицепляет к стейту дополнительную структуру и создает критическую секцию в этой структуре, свою для каждого скрипта (именно поэтому разные скрипты таки могут выполняться параллельно друг другу, у вас - нет). ......
Вы это пишите как разработчик QUIK или как любитель?
Цитата
Anton написал: поэтому разные скрипты таки могут выполняться параллельно друг другу, у вас - нет
Вы прочитали это?:
Цитата
TGB написал: На этом стенде, точно та же моя тестовая программа (16 интенсивно нагруженных потоков в одном Lua-скрипте), работает непрерывно неделями, и я не могу дождаться, когда же она, наконец, упадет.
----- Могу так же поздравить себя с тем, что после упомянутого мною обновления QUIK 8.13.0.106 скорости на «смешанном» коде Lua (с обращениями к С-коду) в QUIK и на моем стенде сравнялись. И куда же делась "затейливость", обеспечивающая высокую скорость QUIK? Причем, в обновленном QUIK мой тест, запущенный вечером 13.04.21 пока работает без проблем. Если он не "обрушит" обновленную версию QUIK до субботы, то скорее всего он дотянет и до следующей субботы. А если это произойдет, то кому что-то будет непонятно?
TGB написал: как разработчик QUIK или как любитель?
Уже не раз говорил, я сорцев квика никогда не видел. Но видел асм. Вы тоже можете на него посмотреть в отладчике, восстановить исходник интересующей части квика и сделать выводы. Это будет ближе к истине, чем пытаться придумать, как квик мог бы работать, если бы его писали вы.
Вы дали ответ только на два мои вопроса (а их всего четыре). Было бы интересно почитать ваши версии ответов на остальные мои два вопроса. Кстати, по поводу возможной оптимизации синхронизации в QLua, вы можете посмотреть мой комментарий в ветке «Средства разработки многопоточных скриптов в QUIK».
Евгений написал: Придется оправдаться за неисправленные ошибки, лучше не читать
)
Читать не читают, но что характерно :: : 1. Мой комментарий был написан 10.04.21. 2. А вчера вечером (13.04.21) мой QUIK 8.13.0.106 совершенно неожиданно для меня автоматически обновился. Возможно это простое совпадение, но на всякий случай я запустил в нем свой тест (с подключением к серверу. Если он не "обрушит" обновленную версию QUIK в течении недели (до 20.04.21) то, наверное, разработчиков QUIK можно будет поздравить. При этом я не исключаю, что действительно поддержка ветку не читает (и особенно, длинные тексты ::)
Не совсем понял Ваш ответ. После обновления на 8.3.0.106 на родной (НЕ измененной) библиотеке lua проблемы исчезли?
TGB написал: Вы дали ответ только на два мои вопроса (а их всего четыре).
Даже на второй слишком лапидарно ответил. Поправлю: мое утверждение о том, что ваш вариант не допускает параллельную работу разных скриптов - неверно, допускает. Однако основное утверждение остается: ваш вариант - это ваш вариант, он сделан по-другому, нежели квиковский, хотя и в том же направлении. Так-то луа встроен во множество приложений, можно было взять из них любое многопоточное и привести как пример, вот, мол, не падает же. Это мало что дает. Интересно было бы воспроизвести в своем хосте похожие AV и докопаться до причины (благо сорцы своего хоста имеются, в отличие от квиковских).
Цитата
TGB написал: по поводу возможной оптимизации синхронизации в QLua
Там тот же биас, что и в приведенных здесь изменениях. А именно, вы непринужденно залезаете в сорцы самого луа и переделываете их под свое видение прекрасного. Арка же, насколько я понимаю, старательно избегает этого. Что-то добавить - да, что-то менять - нет. Это в общем правильная позиция, переделанный луа автоматом становится аркиным творением и все косяки, как привнесенные, так и родные, ложатся на арку. Им это надо? Нет.
Цитата
TGB написал: И куда же делась "затейливость", обеспечивающая высокую скорость QUIK?
Затейливость была про удаление прицепленной структуры. В многопоточном приложении выделение объекта - тривиально, в этот момент о нем знает только выделяющий его поток и может с ним делать что угодно, в том числе и прибить. После того, как объект был показан другим потокам, удалить его - уже нетривиальная задача, надо сначала убедиться, что все потоки в курсе о том, что объект удаляется, и только потом физически удалить.
У вас, например, я не увидел DeleteCriticalSection, потому ли, что вы не нашли, куда бы ее приткнуть? Там есть куда, см. luai_userstateopen, luai_userstateclose, luai_userstatefree. Аналогичные макросы есть для потоков. Хайли лайкли косяк (был?) где-то в этих местах, что-то удаляется слишком рано. Ваш хост даже не пытается эту сторону промоделировать, чего же ему падать-то.
Александр М написал: Не совсем понял Ваш ответ. После обновления на 8.3.0.106 на родной (НЕ измененной) библиотеке lua проблемы исчезли?
После упомянутого мною обновления QUIK 8.13.0.106, скорости на «смешанном» коде Lua (с обращениями к С-коду) в QUIK и на моем стенде сравнялись. Для меня это косвенный признак того, что, в обновленном QUIK 8.13.0.106 синхронизация могла быть реализована, как на моем стенде, то есть, по моему мнению, правильно. Для подтверждения этой гипотезы я в новой версии QUIK запустил 13.04.21 вечером свой тест, который не обновленную версию QUIK "ронял" гарантированно в пределах чуть более одних суток. Сейчас 15.04.21 17.56 тест идет нормально и установлен новый продолжительности его работы. При этом, в обновленном QUIK 8.13.0.106 я не наблюдаю никаких проблем. Если тест не "уронит" QUIK до субботы, то, наверное, можно будет, с большим основанием, предположить, что в обновленном QUIK 8.13.0.106 наблюдаемые мною ранее ситуации устранены, то есть синхронизация реализована корректно.
Anton написал: У вас, например, я не увидел DeleteCriticalSection, потому ли, что вы не нашли, куда бы ее приткнуть? Там есть куда, см. luai_userstateopen, luai_userstateclose, luai_userstatefree. Аналогичные макросы есть для потоков. Хайли лайкли косяк (был?) где-то в этих местах, что-то удаляется слишком рано. Ваш хост даже не пытается эту сторону промоделировать, чего же ему падать-то.
Чем меньше дергаешься, тем реже падаешь Я не ставлю задачу что-то моделировать. Первая задача при разработке любой программы это обеспечение правильности ее работы. В своих разработках программ придерживаюсь некоторых принципов. Вот два из этого списка: 1) Не делай лишней работы. 2) Все, что можно реализуй статически. ----- Если по существу обсуждаемого, то я жду субботы. Если мой тест, запущенный в обновленном QUIK 8.13.0.106, не уронит его до субботы, то для меня это будет признак того, что в обновленном QUIK обсуждаемая синхронизация, скорее всего, наконец, реализована корректно.
Поддержка в ветке так и не проявилась. Но есть и хорошая новость. Тест (это OS_Quesha, запущенная в особо тяжелом режиме тестирования синхронизации в 16 потоках) в обновленном QUIK нормально работает до сих пор (16.04.21 15.28). Никаких аномалий типа утечки памяти, зацикливания и т.д. я в QUIK не обнаружил. Мои попытки «обрушить» QUIK многократными дополнительными запусками из OS_Quesha скрипта в котором есть файловые операции, отладочные операции, операции сереализации и восстановления таблиц, в том числе и _G, не удались. Для меня это означает, что в обновленном 13.04.21 QUIK 8.13.0.106 синхронизация в QLua, наконец, реализована корректно и QUIK, я думаю, стал более стабильным. Похоже, эта эпопея , начавшаяся для меня в мае 2020г. с посылки поддержке первого письма с дампом и с текстом о том, что в QLua 8.5 есть ошибка синхронизации, завершилась.
TGB,А у меня вчера Квик два раза упал на ровном месте. На компе вообще ничего нет, кроме двух Квиков, по одному скрипту в каждом, и вот этого браузера. Ну, ещё Far Manager, в котором я иногда что-нить набиваю. Против падений у меня теперь дамп текущего состояния записывается каждые 5 минут, но при обрыве связи и последующем восстановлении и работающем скрипте этот ублюдок выдаёт колоду прерываний OnTrade по тыщу лет назад исполненным заявкам. Ну просто руки-ноги бы повыдёргивал этим грёбаным программерам!
Теперь поддержка в этой ветке уж точно не появится!
TGB, Эта версия стоит у моего друга. А у меня - 8.7.1.3 и 8.11.0.66. И у меня стойкое ощущение, что чем больше номер версии, тем глючнее содержимое. В конце концов, само обилие версий самым убедительным образом доказывает, что все они говно. Все до единой!
Владимир написал: И у меня стойкое ощущение, что чем больше номер версии, тем глючнее содержимое.
Ну вы консерватор Регрес действительно временами (часто) наблюдается, но в основном, все-таки по принципу один шаг назад, а два вперед. Я понимаю, что вы сами с усами И все-таки, я бы на вашем месте перешел на QUIK 8.13.0.106 и еще бы сделал его обновление последними исправлениями.
TGB, У меня просто большой опыт. И это убеждение сложилось лет за 15-20 до того, как я узнал про существование Квика.
Я могу перейти (у одного из брокеров) именно на неё, только вот когда мой друг на неё перешёл, она ему дня два периодически выдавала сообщение "превышен общий лимит кредитования". А такой диагностики у него не могло быть потому, что не могло быть никогда. Ну и цвет текста в таблице пропадал минимум однажды.
Александр М написал: Не совсем понял Ваш ответ. После обновления на 8.3.0.106 на родной (НЕ измененной) библиотеке lua проблемы исчезли?
После упомянутого мною обновления QUIK 8.13.0.106, скорости на «смешанном» коде Lua (с обращениями к С-коду) в QUIK и на моем стенде сравнялись. Для меня это косвенный признак того, что, в обновленном QUIK 8.13.0.106 синхронизация могла быть реализована, как на моем стенде, то есть, по моему мнению, правильно. Для подтверждения этой гипотезы я в новой версии QUIK запустил 13.04.21 вечером свой тест, который не обновленную версию QUIK "ронял" гарантированно в пределах чуть более одних суток. Сейчас 15.04.21 17.56 тест идет нормально и установлен новый продолжительности его работы. При этом, в обновленном QUIK 8.13.0.106 я не наблюдаю никаких проблем. Если тест не "уронит" QUIK до субботы, то, наверное, можно будет, с большим основанием, предположить, что в обновленном QUIK 8.13.0.106 наблюдаемые мною ранее ситуации устранены, то есть синхронизация реализована корректно.
Спасибо за ответ, логику понял. Как я понимаю, уже к данной версии можно присматриваться. Я пока пользуюсь 8.8.4.3, она работает стабильно у меня.
TGB, Снова Квик гавкнулся. Кажется, причина та же, что была и в прошлых глюках: конфликт утилит прорисовки таблиц и подачи транзакций. По крайней мере, сейчас было так: решил я купить кое-каких акций "вручную" (через всплывающее контекстное меню моего скрипта). По клику на кнопку "купить" у меня там сначала посылается заявка, а потом убивается меню. Так вот: заявка была послана (и даже сработала), а меню осталось на месте "неубиенным" - у Квика крыша съехала, пришлось прибивать весь процесс. По-моему, это уже ТРЕТИЙ глюк на одну и ту же тему! Ну и нахрена вы плодите туеву хучу версий, господа разработчики?
Владимир написал: Снова Квик гавкнулся. Кажется, причина та же, что была и в прошлых глюках: конфликт утилит прорисовки таблиц и подачи транзакций.
Цитата
TGB написал: И все-таки, я бы на вашем месте перешел на QUIK 8.13.0.106 и еще бы сделал его обновление последними исправлениями.
Все версии до выше указанной (с обязательным обновлением после 13.04.21), по моим представлениям, с ошибкой синхронизации в QLua, проявляющей себя в виде похожем на то, что вы описываете. Для разных пользователей эти ошибки могут проявляться по разному.
Не, я пока погожу. В конце концов, эта версия работает на компе моего друга. Вот и посмотрим, как она будет себя вести. Кстати, у меня сегодня упала самая древняя версия, 8.7.1.3.
Владимир написал: TGB , Но не исчезнут они никогда!
Нужно исходить и того, что в более-менее объемной программе, всегда есть ошибка. И все же ошибки, на которые часто"наступают" пользователи, обычно, со временем вычищаются.
Цитата
Владимир написал: Не, я пока погожу. В конце концов, эта версия работает на компе моего друга. Вот и посмотрим, как она будет себя вести.
Если друг не обновит свою версию последними исправлениями, то ее стабильность не будет отличаться от вашей. Надо иметь ввиду, что проявление ошибок синхронизации существенно зависит от что реализуется в скрипте и возможно у вашего друга, вообще со стабильностью нет проблем.
TGB, Ну, меня пока что устраивает нынешняя стабильность, хотя уже и начинает раздражать. И я НЕ ВЕРЮ, что не исправляемые годами глюки вдруг будут вычищены в очередной последней версии, которой, к тому же, без году неделя.
TGB, Наоборот! Я с самого начала (кстати, посмотрев на ветки именно этого форума, где постоянно плакались по самым смехотворным проблемам) решил, что писать буду только на Lua. И примерно за полгода написал всё, что хотел - с полного нуля до полностью удовлетворяющего меня скрипта. Думаю, у меня стабильность В РАЗЫ выше средней по форуму. И я больше не "кувыркаюсь" - так, шлифую в фоновом режиме, если что замечу. Например, вчера нарвался на явление: заявка снимается и через секунду снова ставится. Подрихтовал...
Anton, В это я тоже АБСОЛЮТНО не верю. У меня четверть кода (если не треть) написана исключительно для компенсации различных глюков, возникающих при работе скрипта. И я уверен, что максимум после третьей версии любого софта никаких "крайне интересных инноваций там быть не может. А вот количество глюков от версии к версии неуклонно растёт.
Итак, сегодня суббота. "Уронить" QUIK 8.13.0.106 после 13.04.21 (с последними его исправлениями) мне не удалось. Ни с помощью моего трэшевого теста, ни добавлением к его работе частого запуска "тяжелого" скрипта с разнообразными операциями. Высказанные ранее мною предположения пока подтверждаются.
Тест синхронизации в QUIK 8.13.0.106 после 13.04.21 (с последними его исправлениями) до сих пор не "падает". Для меня это означает, что в этой версии QUIK синхронизация в QLua реализована корректно.
Firefox не знает, как открыть данный адрес, так как один из следующих протоколов (ftp) не связан ни с одной программой или не разрешен в этом контексте. Что это может быть, с браузером что то?
Евгений, да, ваш браузер окончательно скуколдился. Пора переходить на Google Chrome или Microsoft Edge. Для мазохистов еще есть Brave, Opera и старые форки файрфокса.
Артем, Ну да, ну да... цитата из моей давней (2011 год) заметки о браузерах:
Лохотрон №4: война браузеров.
Даже тупорылые признают: После бесславной гибели Netscape реальных "боевых действий" фактически не было. Да и откуда им взяться? Если отвлечься от некоторых оформительских деталей, то все браузеры - и самые старые, и новейшие - близнецы-братья! Иначе и быть не может: браузер по определению есть УНИФИЦИРОВАННОЕ средство отображения информации! Какая разница, какой там у нас стоит браузер, если все они ОБЯЗАНЫ корректно отображать данные, представленные на ЛЮБОМ сайте?! Но нет - мы снова радостно заглотили очередную дурацкую наживку тупорылых! Примеры:
Разница между Firefox и Opera минимальная из-за ожесточённой конкуренции. Прут друг у друга фичи быстрее, чем пользователи успевают заметить отличия.
Microsoft таки сподобились содрать (почти) всю функциональность Opera/Firefox.
Нет никаких причин использовать IE, кроме наличия дурацких сайтов, написанных исключительно (!) под него.
Ни один браузер не считаю удобным. Пользуюсь тремя (!) сразу. Firefox держу ради одного (!) сайта.
Это разница в подходе (Firefox запускает новый процесс, а IE нет). Даже концептуальная. Одна all-in-one, второй "собери сам".
Снимаю шляпу перед тупорылыми! У меня никогда не хватило бы мозгов сообразить, что можно с такой наглостью впаривать быдлу сколь угодно идиотские сказки. Развернуть на 180 градусов саму идею браузера, заставить создавать сайты специально под "универсальное" средство просмотра - это ВЫСШИЙ пилотаж! И одновременно АБСОЛЮТНАЯ характеристика стаду баранов, именующихся продвинутыми юзерами. Именно продвинутыми, ибо они имитируют осознанность выбора.
Какая война, придурки, какая конкуренция?! Это всего лишь цирковое представление, специально для вас. Чтобы вы с упоением выискивали разный там "плагиат". Который, между прочим, применительно к браузеру называется "унификация интерфейса пользователя". Представьте, дуболомы, что в одном языке программирования слово if означает проверку условия, в другом - команду присвоения, в третьем - оператор цикла (чтобы избежать плагиата). Ну и как, нравится?
Война браузеров (грязная, беспощадная!) действительно была, я её и сам видел. Но она была между NN и IE! И в этой войне любые технические нюансы, достоинства и недостатки самих браузеров, не имели НИ МАЛЕЙШЕГО значения! А весь этот нынешний ублюдочный зоопарк из оперных хромированных лис есть лишь ИМИТАЦИЯ войны, лишь разводка для лохов. Я понимаю - вся эта погань из W3C и ниже мечтает рулить финансовыми потоками, она только на этом поганом клиенте ворует бабло десятками миллиардов долларов. НО НАМ-ТО КАКОЕ ДО ЭТОГО ДЕЛО?! Воруют - да и хер бы с ними, но они же еще и СРАТЬ ПРИХОДЯТ НА НАШИ КОМПЫ! Ну почему вы это терпите?! Ну нельзя же быть настолько тупыми, господа!
Есть такая утилита curl.exe кто нибудь знает как ей пользоваться? Можно отправлять https запросы например в телеграм, кто нибудь пользовал ее? Не приходит сообщение, что тут не так function tel_group2(token,chat_id,message1) local chat_id = "-1001203034142" local token = "1665286210:AAGa6lViJ8NDjybSvMIPGYYCDDcmTIAUdhU" local message1 = "Hello Lua" if token and chat_id and message then local s='C:\\curl-7.60.0-win64-mingw-master\\bin\\curl.exe' s=s.."https://api.telegram.org/bot"..token.."/sendMessage?chat_id="..chat_id..&... local msg = os.execute(s) if msg then return true else message("error telegram") return false end end end
Первое по важности это, как мне представляется, ценное предложение Старателя по устранению критической ситуации «подвисания» скриптов на длинных участках чистого Lua (без вызова C-функций). Ссылка на его комментарий: здесь Ниже его комментария есть два моих комментария о том, как это можно просто реализовать в QLua. ----- Второе предложение мое (ссылка на комментарий: здесь). В нем описывается вариант повышения эффективности выполнения в скриптах длинных участков с частым обращениям к коротким C-функциям. ------
Хотелось бы увидеть реакцию поддержки на эти два предложения.
Во избежание взаимного недопонимания, просим собрать оба предложения, на которые Вы ссылаетесь, в одно, максимально емко описывающее суть пожеланий, обращение, здесь или же нам на почту (quiksupport@arqatech.com). Для каждого из двух пожеланий, просьба описать: 1) Непосредственно желаемые изменения (что и как изменить / добавить / убрать) 2) Актуальность / практическую пользу этих самых изменений
Мы обязательно примем данное обращение в работу и постараемся представить итоги его анализа. Заранее благодарим.
Roman Azarov написал: Мы обязательно примем данное обращение в работу и постараемся представить итоги его анализа.Заранее благодарим.
Текст данного комментария со Старателем не согласован, но надеюсь, что если, по его мнению, я написал что-то не то, он меня поправит. --------- Предложение1 (от Старателя). Мое краткое описание ситуации, устраняемое при реализации предложения Старателя, а далее цитаты. Бывают ситуации зависания в QLua, когда основной поток обслуживания колбеков всех скриптов пользователя, а также таблиц QUIK (это не таблицы Lua), блокируется выполнением длинного цикла пользовательской программы на «чистом» Lua, в котором нет ни вызова seep ни вызова других C-функций. ---- Далее цитирую Старателя: «Если цикл продолжительный, чтобы не было зависаний, можно вставить внутрь цикла любую с-функцию (не обязательно sleep). Причём, вставлять можно не на каждую итерацию, а через задан-ное количество циклов. Это позволит не подвешивать основной поток и при этом сохранить ско-рость вычислений байткода в циклах.». --- Далее цитирую себя: Комментарий 1. «То, что предлагает Старатель, наверное, имеет смысл реализовать в самом QLua. Это примерно следующее: 1. Добавить в State поле счетчик. 2. При создании State счетчик = 0. 3. В цикле работы виртуальной машины Lua (исходник Lua 5.3.5 lvm.c) после текста: Instruction i; StkId ra;
добавить: if (++L-> счетчик > !00) { // 100 это конечно же надо задать константой -- L-> счетчик = 0; lua_unlock(L); lua_lock(L); }» --- Комментарий 2. « То, что вы предлагаете (это обращение к Старателю), я сделал (в соответствии с тем, как описал в предыдущем моем комментарии) и проверил на своем стенде. При "количестве циклов" = 1000 обеспечивается высокая скорость выполнения байт-кода и нет зависания. Ваше предложение легко реализуемо в QLua.» --------------------------------------------------------------
Предложение2 (от TGB). Об оптимизации синхронизации в QLua. Не затрагивая существующей архитектуры обработки колбеков в QUIK, можно оптимизировать синхронизацию многопоточности QLua. Дело в том, что при синхронизации по умолчанию, как это, похоже, реализовано в существующей QLua, все вызовы C-функций имеют следующий общий вид: unlock ….; <Вызов C-функции>; lock ……; В операциях unlock и lock возможны переключения потоков. То есть, это ресурсоемкие операции. Если вызываемая C-функция выполняется быстро, как напри-мер, многие математические функции, то при существующей синхронизации, коэффициент полезного использования времени ЦП может быть очень низким : <Время выполнения C-функция > / (< Время выполнения unlock > + < Время выполнения lock >). Понятно, что в циклах QLua с обращением к коротким C-функциям QLua занимается в основном синхронизацией. Идея оптимизации состоит в том, чтобы у пользователя была динамическая возможность задания/отмены C-функций, которые вызываются без выше описанной синхронизации (ввести особый список). Сделать эффективную реализацию выше описанного несложно. Чтобы гарантировать обязательную «щель» для запуска колбеков, из списка допустимых C-функций, описанных в предыдущем абзаце операций, имеет смысл исключить sleep, а возможно, и еще какие-то функции обеспечения задержек по времени и файловые операции. Существенным положительным моментом описанной оптимизации является то, что она никак не затрагивает тех пользователей, которые не будут ее использовать. При ее применении, коэффициент полезного использования времени ЦП: 1) для функций из особого списка: <Время выполнения C-функция > / < Время анализа особого списка> 2) для обычных функций: <Время выполнения C-функция > / (< Время анализа особого списка> + < Время выполнения unlock > + < Время выполнения lock> ). При качественной реализации оптимизации можно добиться того, чтобы < Время анализа особо-го списка> было существенно меньше, чем (< Время выполнения unlock > + < Время выполнения lock>). --------
Предложение1 и Предложение2 совместимы при их совместной реализации, если реализация Предложения1 будет похожа на то, написано в Комментарий 1. Предложение1 устраняет критическую ситуацию. Кроме того его реализация проста. Поэтому Предложение1 имеет смысл реализовать в первую очередь.