Язык Lua. Общие вопросы программирования

[Dennis_Chikin 3 658]

С чего начинать и где взять.

 

Установка Lua:
http://www.amk-team.ru/forum/index.php?showtopic=11584&p=629106

 

Руководство «Программирование на языке Lua», третье издание:
http://www.amk-team.ru/forum/index.php?showtopic=11584&p=905308

Изменено 2 Марта 2015 пользователем Kirgudu

[Artos 99]

Andrey07071977, собственно про coroutine в начале топика нам напомнил и дал информацию Gun12 (#301), а тут (#112) конкретный практический пример использования в игре подпрограммы (созданной не движком, а скриптом) для постоянного сканирования всех локаций по всем игровым объектам.

Однако, хотя информация и полезная, но именно применительно к движковым потокам коллбэков для модмейкеров малоупотребима, т.к. пока практически из скриптов невозможно получить статусы этих потоков и "облегчить отладку коллбэков". :-(

Изменено 21 Января 2012 пользователем Artos

[Andrey07071977 18]

Artos, спасибо, удивительно как я умудрился пропустить пост Gun12 - сэкономил бы кучу времени на вступительной части . Честно говоря не ставил целью научить или обьяснить работу с coroutines, просто не до конца понимал работу колбэков и решил разобраться. malandrinus, пробовал объяснить, но все равно у меня оставался пробел в логической цепочке, поэтому решил смоделировать работу в луа. Подумал может кому еще поможет разобраться с синхронизацией колбэков. Изменено 21 Января 2012 пользователем Andrey07071977

[RvP 1]

По настоянию malandrinus-а опубликовал на гуглокоде проект по фиксу Lua в сталкере.

Ссылка: Code Google

 

Проект подходит к MSVC 2010, требует boost последней версии.

Изменено 21 Января 2012 пользователем RvP

[Unnamed Black Wolf 4]

Artos,

Хмм, статус потока - coroutine.status.

Какой ещё статус нужен? Или тогда яснее, точнее, конкретнее говори.

Изменено 22 Января 2012 пользователем Unnamed Black Wolf

[Artos 99]

Unnamed Black Wolf

Что-то нередко попадаешь 'не в тему', читая НЕ внимательно написанное.

Сказано конкретно:

Artos: ... но именно применительно к движковым потокам коллбэков для модмейкеров малоупотребима, т.к. пока практически из скриптов невозможно получить статусы этих потоков ...

Подскажи, плз, как получить в скриптах игры для, например, потока actor_binder:update(...) иль stalker_binder:hit_callback(...) его статус (coroutine.status)! Изменено 22 Января 2012 пользователем Artos

[xStream 86]

Какие корутины в движке, вы чего? Выполняется С++ логика для объекта, и тут же (в ней же) запускается ЛУА колбек...

[Malandrinus 615]

Тем не менее, если посмотреть с помощью debug.traceback на дамп потоков после подвисания колбека, то видно, что подвисший колбек видно как отдельную нить Lua. И по косвенным данным это видно, поскольку у отдельных колбеков контекст свой, что говорит, что они работают в отдельных нитях Lua. Признаться, я эту механику понимаю не до конца, но не вижу ничего невозможного в том, что отдельный вызов Lua запускается в отдельно создаваемом для него потоке Lua.

[xStream 86]

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

Изменено 22 Января 2012 пользователем xStream

[Malandrinus 615]

Чтобы не было неясности, я естественно не имел в виду потоки Windows.

 

update:

Однако, там на самом деле нет никаких Lua-потоков. Если бы были, то встречались бы вызовы lua_newthread, а ни одного нет. Всего лишь при вызове колбека ему выделяется отдельный стек, который остаётся неразмотанным после сбоя. debug.traceback же просто показывает все стеки: текущий, потоков (если бы они были) и до кучи всех повисших вызовов.

 

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

 

Что касается потоков Lua, то вряд ли им есть какое-то разумное применение в данном случае. Разве что кому-то зачем-то придёт в голову написать свой менеджер кооперативной многозадачности. Но какие задачи в скриптинге под сталкер можно решать с его помощью? В общем, бесполезная вещь.

Изменено 23 Января 2012 пользователем malandrinus

[xStream 86]

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

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

Естественно речь не о виндовых потоках. Просто было соображение на тему, почему это не фатал еррор. Мое соображение такое - происходит ошибка, почему-то не приводящая к вылету, ЛУА тоже не падает, возвращает управление основному потоку и так далее.

[Malandrinus 615]

xStream,

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

Я помню, о чём тема. Я ведь её и создал =) Просто в данном случае в этом обсуждении реально нет никакого практического смысла. Движок на эту тему не изменить.

 

почему это не фатал еррор. Мое соображение такое - происходит ошибка, почему-то не приводящая к вылету, ЛУА тоже не падает,

Ну почему не падает, я могу и так сказать, и в общем и говорил. Происходит исключение С++, движок это исключение ловит и ничего по этому поводу не делает. Поскольку исключение именно С++, то его соответственно не ловит Lua. Потому и вылета нет с руганью на ошибку Lua. Когда происходит ошибка времени выполнения Lua вылет происходит вполне нормально с сообщением в логе. Это если эту ошибку Lua не поймать в свою очередь с помощью pcall, но это уже другой разговор. Для меня здесь непонятным остаётся только, почему прекращаются дальнейшие вызовы, т.е. что именно там после этой ситуации ломается. Но это "что именно" может быть как уровня Lua, так и уровня luabind, так и уровня движка, у которого вокруг luabind накручено ещё своего кода.

[Andrey07071977 18]

malandrinus,

Разве что кому-то зачем-то придёт в голову написать свой менеджер кооперативной многозадачности

В Lua уже есть этот самый менеджер, именно он отвечает за работу coroutines

Если бы были, то встречались бы вызовы lua_newthread, а ни одного нет

а lua_open не встречаются?

Всего лишь при вызове колбека ему выделяется отдельный стек

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

[Malandrinus 615]

Andrey07071977

В Lua уже есть этот самый менеджер, именно он отвечает за работу coroutines

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

 

а lua_open не встречаются?

Ты имеешь в виду lua_newstate? Встречается, но это ни о чём не говорит. Ведь хотя бы один стейт надо создать по-любому.

 

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

нет там в движке coroutines, говорю же. При вызове Lua из СИ выделяется отдельный стек безо всяких новых потоков. Это в документации Lua написано. Потом, создание стейта и создание потока Lua - это две не связанные вещи. Стек у потока отдельный, это да, а стейт уже должен быть создан и может быть и существующий (и скорее всего существующий, видны же все переменные). И насчёт "менеджера". Что ты называешь менеджером? Поток Lua - это вообще-то простая как валенок сущность. Грубо говоря, это просто функция, которая может в любой момент сказать себе остановить своё выполнение и которую можно после этого с этой же точки продолжить. Менеджер чем-то управляет, а здесь нет ничего, кроме того, что сам же и напишешь, так что называть это менеджером как-то язык не поворачивается.

[Unnamed Black Wolf 4]

Подскажи, плз, как получить в скриптах игры для, например, потока actor_binder:update(...) иль stalker_binder:hit_callback(...) его статус (coroutine.status)

Как уже выше говорилось, в принципе это не совсем потоки про которые речь..

[Andrey07071977 18]

malandrinus,

Ты имеешь в виду lua_newstate?

Нет, имел ввиду именно lua_open - ты когда проверял создание Луа потоков искал lua_newthread. А создать поток можно еще и с помощью lua_open. Цитата из вики

 

Each thread in C which interacts with Lua will need its own Lua state. Each of these states has its own runtime stack. When a new C thread is started, you can create its Lua state in one of two ways. One way is to call lua_open. This creates a new state which is independent of the states in other threads. In this case, you'll need to initialize the Lua state (for example, loading libraries) as if it was the state of a new program. This approach eliminates the need for mutex locks (discussed below), but will keep the threads from sharing global data.

 

The other approach is to call lua_newthread. This creates a child state which has its own stack and which has access to global data.

Изменено 23 Января 2012 пользователем Andrey07071977

[Malandrinus 615]

Andrey07071977,

lua_open вроде как устарела и вместо неё используется lua_newstate. Её я и имел в виду. Ссылки на неё встречаются.

А создать поток можно еще и с помощью lua_open. Цитата из вики

По-моему, там описывается ситуация, не имеющая прямого отношения к делу: "каждому потоку С нужен свой Lua-стейт, а стейт можно создать либо с помощью lua_open (и при этом не будет доступа к данным остальных стейтов), либо создать дочерний стейт, создав поток Lua с помощью lua_newthread (нужно использовать мьютексы для исключения конфликтов, но данные будут общими)".

В любом случае lua_open не создаёт поток Lua, а только создаёт стейт.

 

Давай рассуждать логически. При разных вызовах глобальные данные остаются доступными, значит, согласно этой же цитате, это не первый вариант с lua_open (точнее с lua_newstate). Т.е. стейт в общем один. С другой стороны, вызовов lua_newthread нет, значит это и не второй вариант =) Так что xStream права, и никаких coroutines там нет, если только сам их не сделаешь.

 

Что интересно, из этой же цитаты следует, что и потоков С/С++, которые общаются с Lua, в движке всего один, иначе бы как раз и потребовались либо новые стейты либо потоки Lua, а ни того ни другого, как мы выяснили, нет. Это вполне согласуется с моими наблюдениями, поскольку никаких особенных мер по межпотоковой синхронизации я вблизи вызовов Lua из движка не наблюдал. Это потому, что особенно нечего синхронизировать, вся игровая логика обсчитывается строго в один поток. Может быть что-то, связанное с физикой или рендером и требует синхронизации, но там я глубоко не копался.

Изменено 24 Января 2012 пользователем malandrinus

[alpet 77]

Кто-нибудь пытался использовать средства debug для пошаговой (построчной) отладки скриптов в STALKER? У меня как-то не получилось, в колбеки мусор попадает и вызовы не слишком частые - такое подозрение что сильно обрезан отладочный код в XrLua.dll

 

Кстати, lua_newthread я использую для выполнения кода в "песочнице" через LuaSafeCall - позволяет игнорировать мелкие сбои в скриптах такой подход. Для вычислений дополнительными ядрами ЦП, нить лучше создавать полностью новую (lua_newstate), чтобы не включать глобальное пространство имен и доступ к функциям движка (использование чего приведет к сбою наверняка).

[RvP 1]

alpet, все вполне работает. Как вариант - для некоторых функций jit нужно отключать

[Nazgool 250]

alpet

Ты про debug.sethook?

[Nazgool 250]

Ну раз уж нет ответа. то повторю слова RvP - нужно отключить jit.

А в принципе sethook достаточно неплохо (я бы даже сказал - хорошо) отслеживает построчные действия. Так же и вызовы (и callback-и).

Если использовать сам jit, то можно отследить процесс и в байткоде (для особо любознательных и сведущих в этом)

Изменено 1 Февраля 2012 пользователем Gun12