jcmvbkbc, file permissions вы придумали сами, у меня это нигде не упоминалось.
Если говорить про контексте, я в самом начале вам указал, что вы поняли неправильно, но вы начали доказывать что я имел ввиду не то что имел и вы видимо лучше знаете, что имел автор.
Можете и два цикла крутить - в Lineage2, например, монстры обрабатываются одним процессом, игроки другим. Общение через базу данных.
Но в одном потоке вы тоже можете перебирать объекты (игроков и монстров) и кому-то обрабатывать активность каждый тик, кому-то просто помечать счетчик до следующей "активности".
Например статус "дерется", задержка "5". С каждым тиком задержка уменьшается, как станет "0" выполнится "дерется", затем новое действие, возможно с новой задержкой.
Причем вы всегда можете прервать текущий статус, если например монстр "заснул", "оглушен" или еще что-то.
В MUD-ах (старые CRPG), ве монстры и игроки обрабатывались одним циклом. И мы делали заклинания, которые кастовались несколько тиков именно таким способом - добавляли счетчик на активность.
Что означает одновременная битва?
Вам нужно просто посчитать кто победит, или процесс битвы растянуть на несколько секунд?
Просто делайте расчет одного удара для каждого и заверните это в цикл, пока один из врагов не умирает.
Можете делать внутри цикла задержку с привязкой к реальному времени, если хотите растянуть.
Тут даже треды не особо нужны, если у вас нет никакой анимации.
В разных реалтайм играх обычно существует отдельный тред-счетчик, который в вечном цикле крутит actions. То есть пробегает по всем персонажам, смотрит что этот персонаж сейчас делает (идет/стоит/дерется), выполняет для его персонажа кусок его активности (наносит удар, передвигается на xx расстояние, восстанавливает параметры...), тоже выполняется по объектам (что-то там строится, что-то там падает, что-от там открывается/закрывается).
В идеале вся эта активность умещается в пределах 1 секунды, а то и меньше, чтобы "тики" были одинаковые.
Можно крутить отдельные независимые треды для игроков, для монстров, для зданий, для ивентов. Или вообще отдельные процессы.
Можно крутить активность чаще или реже, просто синхронизироваться с часами реального времени.
Что означает одновременная битва?
Вам нужно просто посчитать кто победит, или процесс битвы растянуть на несколько секунд?
Просто делайте расчет одного удара для каждого и заверните это в цикл, пока один из врагов не умирает.
Тут даже треды не особо нужны, если у вас нет никакой анимации.
В каком файле?
профайл грузится при логине.
Если вы залогинились и поменяли PATH, то до конца сессии у вас уже будет текущий PATH
Как минимум перелогиньтесь. И перепроверьте ваш PATH обычным способом -
echo $PATH
Я думаю, что вы считаете исключительно денежные затраты, без учета организационных моментов.
А в бизнесе они важны.
Найти нормального админа, которому можно доверить доменные пароли и чужие почтовые ящики. И чтобы этот админ все 10 лет сидел в твоей компании, а не менять его каждые 3-5 лет.
Бэкапы - в гугл клауд каждый ящик сам по себе, свой упавший exchange - это стоп для всех юзеров.
Обновления и патчи от МС, перезагрузки, да сам exchange уже раза три обновлялся.
И да, вы очень недооцениваете маскишоу. Не стоит исключать этот аргумент.
Kyubey, в c/c++ утечки легче устранить и легче создать. Java была спроектирована так, чтобы вообще не заниматься вопросом утечек - для этого работает внутренний механизм garbagecollector, поэтому на самом деле утечка в джаве встречается на порядки реже, чем в С/C++.
сравнительные бенчмарки которые делают что?
Вы же понимаете, что скорость разработки на языке зависит даже не столько от языка, сколько от ваших знаний и опыта работы с языком.
Большинство проблем, которые вы описали, чаще применяются не к самому языку а к выбранным библиотекам/фреймворкам, что опять таки - огромный пласт знаний и опыта, который учится в разы дольше самого языка.
Отрендерить 3д видео наверное будет быстрее в C++ и медленнее в PHP, но обратиться в базу данных и сгенерировать веб-страничку - PHP может легко обогнать С++, потому что fastcgi (точнее PHP-FPM).
Опять же, чинить нужно не язык программирования, а bottle neck.
Случай из жизни - игровой проект, онлайн около 100к, стратегия с боями.
На старте проекта бои с минимальным количеством юнитов. Через год уже тысячи. Просчет боя занимает минуты. Еще через год флоты выросли до миллиона, на сервере не хватает оперативки, бои топовых альянсов считает по 2 часа.
Пишем модуль к apache, в котором бой рассчитывает ассемблерная вставка.
Топовый бой просчитался за 2 секунды, проблем с памятью нет.
Другими словами, предварительная оптимизация может угрожать задержками вплоть до вообще нереализованного проекта
Если говорить про контексте, я в самом начале вам указал, что вы поняли неправильно, но вы начали доказывать что я имел ввиду не то что имел и вы видимо лучше знаете, что имел автор.