www.mudconnector.su
https://forum.mudconnector.su/

Синхронизация итп, отделено.
https://forum.mudconnector.su/viewtopic.php?f=14&t=789
Страница 5 из 5

Автор:  ArtistSpb [ Сб дек 27, 2014 1:15 am ]
Заголовок сообщения:  Re: Синхронизация итп, отделено.

Kalevala писал(а):
Что касается Lua в нем есть библиотека coroutine из хелпа по Lua
Lua поддерживает подпрограммы, эту технологию часто называют общей многопоточностью.
Подпрограмма Lua представляет собой независимый поток выполнения. Несмотря на это, в отличие от потоков в традиционных многопоточных системах, подпрограмма может приостановить свое выполнение только в результате явного вызова функции yield.
Что-то такое наверное можно, но я не копал там глубоко. Пока вроде не требуется.


Многопоточность в Lua - это не тоже самое, что многопоточность в операционной системе. В луа - она реализована через сопрограммы (коротины).
Одновременно может выполняться только одна сопрограмма, но она может прерваться (только по своему желанию через yield, что является главным минусом ИМХО)
и тогда запустится другая сопрограмма. Позднее после возвращения в первую сопрограмму, будет восстановлен стек и др. для продолжения ее работы.
Т.е. можно параллельно запустить хоть 1000 сопрограмм, но работать будет только одна, т.е. параллельность обеспечивается путем переключения от одной программы к другой,
но для того чтобы это работало, сопрограмма сама должна себя остановить.
Этот подход не годится для скриптов, которые будут делать билдеры, так как он влияет на работу всего мада. Но годится для программирования сервера/ядра. Сопрограммы
клевая вешь, если ее применять по предназначению.

Kalevala писал(а):
Надо как-то автоматизировать процесс.
Иначе не напроверяешься... т.е. в семантике мобпрограммы-на-луа проверок после каждого wait быть не должно,
они должны делаться автоматом. Беглое рассмотрение вопроса дает довольно большой объем частностей.
Это всё проходимо, проходимо вообще всё :), меня интересовало как другие решали такие проблемы. (если решали)


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

Автор:  Kalevala [ Сб дек 27, 2014 2:12 am ]
Заголовок сообщения:  Re: Синхронизация итп, отделено.

ArtistSpb писал(а):

Kalevala писал(а):
Надо как-то автоматизировать процесс.
Иначе не напроверяешься... т.е. в семантике мобпрограммы-на-луа проверок после каждого wait быть не должно,
они должны делаться автоматом. Беглое рассмотрение вопроса дает довольно большой объем частностей.
Это всё проходимо, проходимо вообще всё :), меня интересовало как другие решали такие проблемы. (если решали)


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


Ну вот это не я писал ))
Именно так. Скрипт прервется и вылетит с ошибкой. Сервер не пострадает, если нет кривостей в реализации функций взаимодействия Си<->Lua
Объекты надо проверять в самом скрипте во избежание некорректной работы скрипта, но проверки там тупо на nil или на соответствие ожидаемому.

Автор:  Pacifist [ Сб дек 27, 2014 11:22 am ]
Заголовок сообщения:  Re: Синхронизация итп, отделено.

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

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

Автор:  ArtistSpb [ Сб дек 27, 2014 11:44 am ]
Заголовок сообщения:  Re: Синхронизация итп, отделено.

Я кстати тоже смотрю на го как вариант для главного языка разработки,
еще смотрю в сторону erlang-а. Сейчас обложился книгами. Изучаю что к чему.
В первую очередь смотрю ключевые моменты - интеграция с с++ поддержка
многопоточности. Я от луа не отказываюсь, так как по прежнему считаю его
кандидатом номер 1 на внутренний язык скриптов. Его же в качестве протокола
вместо телнета.
Скорее всего надо начинать со списка задач технического плана и прототипирования.
Первый сервер будет экспериментом в целях изучения возможностей.

Автор:  Pacifist [ Сб дек 27, 2014 1:06 pm ]
Заголовок сообщения:  Re: Синхронизация итп, отделено.

ArtistSpb писал(а):
Я кстати тоже смотрю на го как вариант для главного языка разработки,
еще смотрю в сторону erlang-а. Сейчас обложился книгами. Изучаю что к чему.
В первую очередь смотрю ключевые моменты - интеграция с с++ поддержка
многопоточности. Я от луа не отказываюсь, так как по прежнему считаю его
кандидатом номер 1 на внутренний язык скриптов. Его же в качестве протокола
вместо телнета.
Скорее всего надо начинать со списка задач технического плана и прототипирования.
Первый сервер будет экспериментом в целях изучения возможностей.


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

Я не программист, но перечислю достоинства Go с точки зрения обывателя:

1. Go всегда копирует переменные во вспомогательные функции и методы из основной программы, то есть, если не давать билдеру контроля над памятью, то билдер никогда не сможет уронить сервер своими неосторожными действиями.

2. Нативная поддержка UTF-8 вплоть до того, что в теле программы можно использовать названия переменных, констант и функций на кириллице. Что для билдера может быть проще и понятнее. Например, вместо малопонятного кода: "Миша нажал%actor.y% рычаг", писать что-то вроде: "Миша нажал+" /а/о" рычаг". Не надо лезть в справку, чтобы разобраться, что же значит этот actor.y.

3. У Go есть поддержка автоматического тестирования пакетов. То есть, движок сможет автоматически отбрасывать плохой код, который билдер попытается в него внести.

4. Go простой. Я не освоился еще в нем со всякими каналами и интерфейсами, но циклы и простые функции писать на нем элементарно.

5. Go быстрый. Ниже привожу сравнительный график скорости разных языков, но он староват, теперь Go еще быстрее.

Вложения:
benchmark.png
benchmark.png [ 12.08 KIB | Просмотров: 9539 ]

Автор:  ArtistSpb [ Сб дек 27, 2014 5:50 pm ]
Заголовок сообщения:  Re: Синхронизация итп, отделено.

Pacifist писал(а):
Я не думаю, что использование отдельного языка для внутренних скриптов является прогрессивным подходом. Мне кажется, что цепочка игрок->билдер->кодер (заинтересованный игрок становится билдером, опытный билдер через какое-то время становится кодером движка) намного интереснее и перспективнее. Если использовать изолированный от движка язык, человек, изучающий его через какое-то время упрется в потолок и его развитие остановится.

Вывод неправильный. Использование отдельного языка наоборот является правильным подходом, если это отвечает задаче. Каждый язык, как и любой инструмент
хорош в месте своего предназначения. Использование Go как внутренний язык - пока под сомнением у меня, но не исключаю такой вариант совсем.
И кстати опять же наоборот, знание только одного языка программирования, например Go, останавливает человека в развитии. Чем больше человек знает языков, тем лучше.
Ведь сейчас на С можно написать все что угодно, зачем придумывают все новые и новые языки ? Почему решили в мадах сделать чтото DGScripts ? Пусть бы все писали
на С прямо в ядре...

Pacifist писал(а):
1. Go всегда копирует переменные во вспомогательные функции и методы из основной программы, то есть, если не давать билдеру контроля над памятью, то билдер никогда не сможет уронить сервер своими неосторожными действиями.

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

Pacifist писал(а):
2. Нативная поддержка UTF-8 вплоть до того, что в теле программы можно использовать названия переменных, констант и функций на кириллице. Что для билдера может быть проще и понятнее. Например, вместо малопонятного кода: "Миша нажал%actor.y% рычаг", писать что-то вроде: "Миша нажал+" /а/о" рычаг". Не надо лезть в справку, чтобы разобраться, что же значит этот actor.y.

Использование русских букв - плохая практика. Будет каша в коде скриптов. Есть пример - код для 1С бухгалтерии. По хорошему нужны определенные несложные правила
кодирования скриптов для билдеров. Этот подход позволяет исключить много проблем в будущем.

Pacifist писал(а):
3. У Go есть поддержка автоматического тестирования пакетов. То есть, движок сможет автоматически отбрасывать плохой код, который билдер попытается в него внести.

У Луа подобное тоже есть, например. Я тут тоже попробую почитать и разобраться в этом плюсе Go.

Pacifist писал(а):
4. Go простой. Я не освоился еще в нем со всякими каналами и интерфейсами, но циклы и простые функции писать на нем элементарно.
5. Go быстрый. Ниже привожу сравнительный график скорости разных языков, но он староват, теперь Go еще быстрее.


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

Главный минус против Go в задаче мад-движка - язык компилируемый. Я не смогу на лету менять нужные аспекты игры не перезагружая сервер.
По сути Go сильно улучшенный C. По сути получится точно такой же мад движок, как все движки сейчас, где для новой фишки придется останавливать
сервер, компилировать его и запускать в работу. А вот с помощью Lua можно делать изменения на лету.

Автор:  Pacifist [ Сб дек 27, 2014 6:49 pm ]
Заголовок сообщения:  Re: Синхронизация итп, отделено.

ArtistSpb писал(а):
Использование русских букв - плохая практика. Будет каша в коде скриптов. Есть пример - код для 1С бухгалтерии.


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

ArtistSpb писал(а):
Главный минус против Go в задаче мад-движка - язык компилируемый. Я не смогу на лету менять нужные аспекты игры не перезагружая сервер.
По сути Go сильно улучшенный C. По сути получится точно такой же мад движок, как все движки сейчас, где для новой фишки придется останавливать
сервер, компилировать его и запускать в работу. А вот с помощью Lua можно делать изменения на лету.


Ну, если это принципиальный вопрос, можно воспользоваться подходом lpmud'ов, они написаны на с и с++, но все изменения там вносятся без перезагрузки, на лету. Они вообще перезагрузки не требуют. Так что, все решаемо.

Автор:  Kalevala [ Сб дек 27, 2014 6:55 pm ]
Заголовок сообщения:  Re: Синхронизация итп, отделено.

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

Автор:  KadVar [ Пн дек 29, 2014 12:34 pm ]
Заголовок сообщения:  Re: Синхронизация итп, отделено.

Pacifist писал(а):
Я не программист, но перечислю достоинства Go с точки зрения обывателя:

Это всё перекрывается простым и мощным недостатком "его не учат в институтах"...
А описанные преимущества на мой взгляд особо не преимущества вовсе, так... фичи.

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

Страница 5 из 5 Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/