www.mudconnector.su

Национальный мадконнектор.
Текущее время: Чт мар 28, 2024 11:26 pm

Часовой пояс: UTC + 3 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 49 ]  На страницу Пред.  1, 2, 3, 4, 5
Автор Сообщение
 Заголовок сообщения: Re: Синхронизация итп, отделено.
СообщениеДобавлено: Сб дек 27, 2014 1:15 am 
Не в сети

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


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

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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Синхронизация итп, отделено.
СообщениеДобавлено: Сб дек 27, 2014 2:12 am 
Не в сети

Зарегистрирован: Пт дек 26, 2014 1:14 am
Сообщений: 20
ArtistSpb писал(а):

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


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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Синхронизация итп, отделено.
СообщениеДобавлено: Сб дек 27, 2014 11:22 am 
Не в сети

Зарегистрирован: Пт сен 04, 2009 10:17 pm
Сообщений: 214
Если писать новый сервер, то мне кажется, лучше использовать вместо луа Go. Я начал его изучать, и он мне кажется не намного сложнее того же самого dg_scripts, но при этом он намного мощнее (на нем можно написать сервер от начала и до конца) и многопоточен. Описанной выше проблемы в нем просто не возникнет, так как текст триггера можно посылать в отдельный канал, и безболезненно прервать этот канал, при невыполнении каких-то условий.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Синхронизация итп, отделено.
СообщениеДобавлено: Сб дек 27, 2014 11:44 am 
Не в сети

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Синхронизация итп, отделено.
СообщениеДобавлено: Сб дек 27, 2014 1:06 pm 
Не в сети

Зарегистрирован: Пт сен 04, 2009 10:17 pm
Сообщений: 214
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 | Просмотров: 9540 ]
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Синхронизация итп, отделено.
СообщениеДобавлено: Сб дек 27, 2014 5:50 pm 
Не в сети

Зарегистрирован: Пн май 27, 2013 4:34 pm
Сообщений: 105
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 можно делать изменения на лету.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Синхронизация итп, отделено.
СообщениеДобавлено: Сб дек 27, 2014 6:49 pm 
Не в сети

Зарегистрирован: Пт сен 04, 2009 10:17 pm
Сообщений: 214
ArtistSpb писал(а):
Использование русских букв - плохая практика. Будет каша в коде скриптов. Есть пример - код для 1С бухгалтерии.


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

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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Синхронизация итп, отделено.
СообщениеДобавлено: Сб дек 27, 2014 6:55 pm 
Не в сети

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Синхронизация итп, отделено.
СообщениеДобавлено: Пн дек 29, 2014 12:34 pm 
Не в сети
Site Admin

Зарегистрирован: Пт май 16, 2008 4:14 pm
Сообщений: 1416
Pacifist писал(а):
Я не программист, но перечислю достоинства Go с точки зрения обывателя:

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

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 49 ]  На страницу Пред.  1, 2, 3, 4, 5

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на конференции


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron