Anton (Все сообщения пользователя)

Представьте, что во втором потоке выполняется та же самая функция. Первый поток выполняет local t = tid, переключается поток, второй поток выполняет local t = tid. Теперь без разницы, в каком порядке потоки выполняются дальше, они оба видят t != nil и оба вызывают DestroyTable, один из них - на уже убитой таблице. И это мы смотрим на простейший пример, где ничего страшного не произойдет. А на других примерах - произойдет. Это типичнейший паттерн вообще-то, как тут можно НЕ увидеть проблем...


Об чем и речь, весь код У ВСЕХ будет в этих костылях просто потому, что вам кровь из носу хотелось чонить в квике починить, пусть даже и не сломанное.

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

Какие блокировки длинным кодом? Где про это говорилось-то? Смотрите:
Видите? Я табличку атомарно спрятал в локальную переменную и спокойно удалил. Когда DestroyTable снимает лок, мейн видит вместо таблички нил и все правильно понимает. После вашего улучшения такое без критической секции не сделаешь, а их в луа нет, если помните. Придется ради вот этой фигни извращаться. И так на каждой строчке.

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

TGB,  я не понимаю, чего вы от меня хотите. Вам стало скучно, вы придумали какую-то околесицу и пытаетесь ее всем навязать. Мне не нужны случайные переключения контекста посреди байткода. Мне они помешают. Я против вашего предложения. И многие будут против, когда на практике увидят, что из этого получится. Надеюсь не увидят. А форк или не форк мне не интересно.

Посмотрите еще раз в той ветке, там все изменения в луа находятся в файле config.h и включают только (пере)определение предназначенных для кастомизации макросов и необходимые forward declarations. Поэтому да, я наверное скажу, что форком то предложение не являлось. Это кастомизация штатными средствами луа.

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

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

Там вы как раз неправильно делаете правильные вещи ) То же самое достигается без изменения кода луа.

TGB,  вы предлагаете создать форк луа и встроить в квик именно форк. Это дорога в ад. Надеюсь, в арке это понимают.

Картинка выше не из квика, с биржи. Имеем что? Биржа дает последний тик часа по 2797 и та же биржа рисует час с закрытием 2811. Эти данные через квик не идут и арка тут никаким боком не замешана. Вопрос таки к бирже.


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

Клиенту сбера, заметим, а не их клиенту. У клиента завсегда есть таблица обезличенных сделок, он может в ней поискать, а по какой же цене была последняя сделка в 18 часов? И увидеть нечто типа такого



А потом, может быть, сходить на биржу и спросить, а чо вы на сайте за циферки показываете?

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

Это вряд ли.

Читается напрямую из хранилища. Вряд ли арка одобрит публикацию описаний подобного рода.

Уже сменил локацию, теперь когда до сорцев доберусь.

https://forum.quik.ru/messages/forum10/message49968/topic5932/#message49968 Вообще-то для луа писалось, но тестовый скрипт там ровно это самое и делает, только без экспорта (зато там либа есть, из луа можно в файл записать). Ссылка протухла, перезалил, пару недель проживет, а попозже к вам заброшу, если не против.

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

При ближайшем рассмотрении оказалось, что моя метода устарела, в 8.13.1.16 тоже не воспроизводится, новее пока нет, чтобы проверить. Сорри фор инконвениенс.

Как повторить:
1) создать твс со всеми подписками;
2) открыть тиковый график по любому инструменту;
3) закрыть тиковый график;
4) убедиться, что фильтр по этому инструменту сбросился.

Либо:
1) создать твс со всеми подписками;
2) подписаться на тики по любому инструменту в луа-скрипте;
3) отписаться от тиков в луа-скрипте или просто выйти из него;
4) убедиться, что фильтр по инструменту сбросился.

Причина:
в секции [ALL_TRADES_DATA] файла info.ini отсутствует рефкаунтинг, первая же отписка приводит к сбросу фильтра.

Возможные решения:
1) никогда не сбрасывать фильтры при отписках (простое решение, предложенное Старателем тыщу лет назад);
2) переделать секцию [ALL_TRADES_DATA] (и работающий с ней код) с использованием счетчиков подписок.

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

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

Владимир, выглядит как наброс с целью определить, сколько тут постигших дзен. А зачем, что потом с этими просветившимися делать?

Если собираетесь заказывать свечки, вполне допустимо. А вот на тики подписываться в цикле не стоит (не дождетесь завершения цикла в разумные сроки).

Денис,  here you are.

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

Они не ждут очереди, ждет квик, мейны выполняются как выполнялись. Если не спят конечно, а если спят то и вопросов никаких, локи выпущены, квик просто дергает колбек и все. (О преимуществе длинного слипа тксть).

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

Первый вариант - мейны удобно выпускают лок в том порядке, в каком квик их хочет вызывать (заштриховано - квик стоит на локе; от красной линии до первого колбека он тоже стоит, не нарисовал этот момент)




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



 

Старатель,  да, все так. Угадывать особо и не нужно, если у нас среднее время выполнения колбека достаточно мало, все будет работать, с поправкой на вызываемый "тупящими" колбеками джиттер. Если среднее время велико (больше среднего времени между колбеками), квик в конце концов забьет свою очередь сообщений и мы увидим любимое окошко "программа не отвечает, казнить нельзя помиловать". Правило одно, стараться не держать колбеки.

Таки нет. Ранее написанное - с точки зрения одного скрипта. Представьте другую картинку, посередине поток квика, а слева и справа ДВА потока мейнов двух скриптов. Если смотреть только на пару "левый скрипт - квик" или только на пару "правый скрипт - квик", все сказанное в силе. Да и в целом общая картинка тоже порезана горизонтальными линиями, только для левой и правой частей они не совпадают. Не знаю, без картинки трудно наверное представить.

Будет вызван в момент t1, второй и трейтий скрипты продолжат выполнять свой байткод, пока первый будет выполнять колбек. Только что проверил.

Вот тут смешной ответ. Скрипт 3 не повлияет, а скрипт 1 повлияет. Как так? У квика не возникает необходимости вызвать колбек только в скрипте 1, он последовательно вызовет колбеки в скриптах 1, 2, 3, и всегда в этом порядке. Если какой-то из скриптов просто не определил колбек, ну слава богу, баба с возу. Так вот, если картинку перевернуть, то есть скрипт 1 самый тормозной (t1 самый длинный), то колбек в скрипте 1 все равно выполнится в момент t1, несмотря на то, что скрипты 2 и 3 уже закончили байткод и по идее можно было бы дернуть этот же колбек в них.

Нет, лок у каждого скрипта свой. Можно, наверное, придумать какой-нибудь сценарий по типу обедающих философов, навскидку такой на ум не приходит.

Уточним. Основной поток квика, в котором вызываются колбеки, выполняется параллельно с потоками мейнов всех скриптов. Насколько эта параллельность честная (на отдельных ядрах) - определяется операционной системой и повлиять на это нельзя. В моменты конкуренции за разделяемый ресурс (луа-машину) основной поток квика ожидает освобождения ресурса потоком мейна того скрипта, в котором он собирается вызвать колбек; мейны других скриптов при этом продолжают выполняться и не влияют на ожидание. И обратно, поток мейна скрипта ожидает освобождения ресурса основным потоком квика; мейны и колбеки других скриптов опять же не влияют.

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

Arrigo,  походу имеется в виду то, что было в борландовском билдере (кажется), когда все мди-дети вываливались на рабочий стол каждый сам по себе, и меню отдельным тулбаром. По мне так аццкий был режим, бестолковый. А если по букве, то мди и есть как раз многооконный режим, прикольно.

Посмотрите на lua_rawequal, например. Она из сей без лока выполняется, по идее слоты никуда не денутся с текущего стека, сравнивай не хочу. Вроде на первый взгляд так и есть, а дальше там посмотрите, там и за строками лазит, и метаметоды может дергать, и на стек слоты добавлять. И все без лока. Вот один из примеров, как может стек поломаться, там еще есть такого добра, если порыться. А в идеальном мире не должен стек ломаться, да.

Ничего там не вычищается. У колбеков свой стек отдельный, поэтому в нем и нет ничего.

А тут я б не поручился, на первый взгляд доступ к таблице тоже чисто байткод, но там внутри может дернуться метаметод, а он может дернуть сишное что-нибудь; при добавлении нового поля может дернуться коллектор, а там вообще мрак полный, кто там сейчас на очереди к удалению и есть ли у него финализаторы и не сишные ли они и т.д., в общем уже не отследить это все. Интересно вот что, если этот кусок таки окажется атомарным, то от зависания мы не ушли, получается? Тогда, получается, функцию Claster надо намеренно сделать неатомарной? Или я перемудрил уже?

Зато сам поллинг - архитектура.

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

Это не оптимизация, это вы архитектуру закладываете заведомо кривую. Потом ее "оптимизировать" - это переписать заново, вот это, видимо, и будет то самое полезное дело, куда полезнее, чем сразу написать ровно.

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

Архив больше? Там две длл, для core и mime. Если каждая длл больше, то скорее всего потому, что здесь рантайм встроенный, в других, видимо, отдельный. Скиньте какую-нибудь из этих других длл, посмотрю точно.

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

Ой. Прям вот на простейшую задачу сразу ядро отдадим? А если на компе два квика, то два, да? И принимающую сторону так же сделаем, еще два ядра минус. Ну а если уж нам задачу поставят UKF посчитать, мы сразу выкатим требования на датацентр, не меньше. Интел одобряет.

Да это моделька же.

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

Вот так, ежли ничего не упустил опять

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

Старатель,  что-то я протупил в аккурат до закрытия, теперь на ходу не проверить, а мысль пошла в такую сторону

А оно ведь тоже подвесит на первом же колбеке?

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

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

Будут-будут, главное не спешка, главное неуклонность. А вот в 8.13 добавилась vcomp140.dll, это крайне интересная инновация.

На фтп положили свежачок. Оно, видимо.

Даже на второй слишком лапидарно ответил. Поправлю: мое утверждение о том, что ваш вариант не допускает параллельную работу разных скриптов - неверно, допускает. Однако основное утверждение остается: ваш вариант - это ваш вариант, он сделан по-другому, нежели квиковский, хотя и в том же направлении. Так-то луа встроен во множество приложений, можно было взять из них любое многопоточное и привести как пример, вот, мол, не падает же. Это мало что дает. Интересно было бы воспроизвести в своем хосте похожие AV и докопаться до причины (благо сорцы своего хоста имеются, в отличие от квиковских).

Там тот же биас, что и в приведенных здесь изменениях. А именно, вы непринужденно залезаете в сорцы самого луа и переделываете их под свое видение прекрасного. Арка же, насколько я понимаю, старательно избегает этого. Что-то добавить - да, что-то менять - нет. Это в общем правильная позиция, переделанный луа автоматом становится аркиным творением и все косяки, как привнесенные, так и родные, ложатся на арку. Им это надо? Нет.

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

У вас, например, я не увидел DeleteCriticalSection, потому ли, что вы не нашли, куда бы ее приткнуть? Там есть куда, см. luai_userstateopen, luai_userstateclose, luai_userstatefree. Аналогичные макросы есть для потоков. Хайли лайкли косяк (был?) где-то в этих местах, что-то удаляется слишком рано. Ваш хост даже не пытается эту сторону промоделировать, чего же ему падать-то.

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

Ага.