А можно спросить, что из этого ошибки, если это всё — вполне описанное поведение языка?
Придирка к опечаткам уровня «не там поставил точку с запятой» — выглядят совсем странными.
К сожалению, мобильной версией пользоваться ну совсем неприятно.
Чего только стоит отсутствие лоадера комментариев, отчего весело видеть «комментарии: 0» и никакого сообщения об их загрузке, лишь едва заметный индикатор-фиг-знает-чего" вверху страницы.
Советую посмотреть на Omega2, построенную на том же MIPS, что и LinkIt Smart. Там же и экранчики навесить можно, и тд, и тп. Документация открыта (и весьма неплохая), бутлоадер тоже, бери и пиши что надо.
Учитывая, что возгласы «мы всё переписали!» были слышны от них начиная с 1.8 и по 1.13 (сейчас), у меня ОЧЕНЬ плохое предчувствие.
Игра течёт. Да, они привели в порядок архитектуру внешне, но внутри там всё тот же ад, усложненный динамическими билдерами, NBT-парсерами и прочей шелухой, из-за которой игра потребляет-высвободжает около 200-300мб\с… А в мультиплеере еще хуже. Вот, к примеру, график потребления памяти практически ванильного (Spigot с парой плагинов) сервера на 1.13:
В итоге после 20-30 игроков серверу становится совсем плохо и TPS (количество тиков в секунду, должно быть 20, по 50мс на тик) стремится к 15, а после и к 10.
Большие надежды подаёт Bedrock-версия, которая на C++, но моды… Они решили туда внести своё «изобретение» — Datapacks, это по сути JSON-файлики с описанием ресурсов. И команды, которые исполняются каждый тик. По сравнению с настоящими модами (IndustrialCraft, Botania, Forestry, Twilight Forest) — это просто медленная игрушка, не пригодная для реального использования, так, побаловаться разве.
Им бы архитектора нанять, который бы сделал сервер наконец многопоточным (потому что пока приходится пилить всё самому, к сожалению, вбухивая кучу человекочасов на то, что по-идее должно быть по умолчанию), не таким раздутым и быстрым.
Мне бы понять чем файбер от корутины с точки зрения прикладного подхода отличаются :) Понятно, что это не для perfomance-dependent вычислений, но есть ли какая-то особая разница между ними, к примеру, в обработке подключений клиента? Или по-факту одно и тоже, но по разному выглядящее?
У меня схожий подход, проблема лишь в том, что иногда приходится делать что-то для продакшна, и возникают вопросы по технологиям :)
Цитируя StackOverflow:
A Fiber is a lightweight thread that uses cooperative multitasking instead of preemptive multitasking. A running fiber must explicitly «yield» to allow another fiber to run, which makes their implementation much easier than kernel or user threads.
A Coroutine is a component that generalizes a subroutine to allow multiple entry points for suspending and resuming execution at certain locations. Unlike subroutines, coroutines can exit by calling other coroutines, which may later return to the point where they were invoked in the original coroutine.
A Green Thread is a thread that is scheduled by a virtual machine (VM) instead of natively by the underlying operating system. Green threads emulate multithreaded environments without relying on any native OS capabilities, and they are managed in user space instead of kernel space, enabling them to work in environments that do not have native thread support.
Я правильно понимаю, получается, что корутина прерывается только в момент await, а fiber — в момент, когда этот самый fiber говорит «я уже доделал»? Из статьи не особо понятно, чем этот подход отличается от конкретно корутин :)
На самом деле уже начинаешь путаться в этих fibers, asyncio, корутины, etc…
Никак не могу найти хорошего материала, когда какую технологию использовать и как.
Я правильно понимаю — если читаешь много или пишешь в сеть/файл — лучше использовать fibers/async/coroutines + пул потоков (к примеру, как делает Netty + Executors.newFixedThreadsPool()); если же обрабатываешь много данных (к примеру, эмуляция игрового мира), то лучше разбить всё по обычным потокам?
Был бы безумно рад, если б кто кинулся какой-нибудь книжкой-умной статьёй :)
Нет, можно поднять Background service и попросить пользователя отключить энергосбережения для конкретного приложения, буквально на ОК нажать. Xabber и Conversations так делают.
Есть и другая идея — забугорным десктопным клиентам показывать плашку «мы — против цензуры, хотите помочь нам?» и при клике на «Yes» через UPNP открывать порт во внешку. Когда накопится достаточное количество таких хостов, через пуши плавненько раздавать их клиентам как relay-сервера.
(Конечно, куча проверок на доступности хостов и тд, тут сама идея описана)
Спасибо!
Придирка к опечаткам уровня «не там поставил точку с запятой» — выглядят совсем странными.
Чего только стоит отсутствие лоадера комментариев, отчего весело видеть «комментарии: 0» и никакого сообщения об их загрузке, лишь едва заметный индикатор-фиг-знает-чего" вверху страницы.
Игра течёт. Да, они привели в порядок архитектуру внешне, но внутри там всё тот же ад, усложненный динамическими билдерами, NBT-парсерами и прочей шелухой, из-за которой игра потребляет-высвободжает около 200-300мб\с… А в мультиплеере еще хуже. Вот, к примеру, график потребления памяти практически ванильного (Spigot с парой плагинов) сервера на 1.13:
В итоге после 20-30 игроков серверу становится совсем плохо и TPS (количество тиков в секунду, должно быть 20, по 50мс на тик) стремится к 15, а после и к 10.
Большие надежды подаёт Bedrock-версия, которая на C++, но моды… Они решили туда внести своё «изобретение» — Datapacks, это по сути JSON-файлики с описанием ресурсов. И команды, которые исполняются каждый тик. По сравнению с настоящими модами (IndustrialCraft, Botania, Forestry, Twilight Forest) — это просто медленная игрушка, не пригодная для реального использования, так, побаловаться разве.
Им бы архитектора нанять, который бы сделал сервер наконец многопоточным (потому что пока приходится пилить всё самому, к сожалению, вбухивая кучу человекочасов на то, что по-идее должно быть по умолчанию), не таким раздутым и быстрым.
Цитируя StackOverflow:
Я правильно понимаю, получается, что корутина прерывается только в момент await, а fiber — в момент, когда этот самый fiber говорит «я уже доделал»? Из статьи не особо понятно, чем этот подход отличается от конкретно корутин :)
Никак не могу найти хорошего материала, когда какую технологию использовать и как.
Я правильно понимаю — если читаешь много или пишешь в сеть/файл — лучше использовать fibers/async/coroutines + пул потоков (к примеру, как делает Netty + Executors.newFixedThreadsPool()); если же обрабатываешь много данных (к примеру, эмуляция игрового мира), то лучше разбить всё по обычным потокам?
Был бы безумно рад, если б кто кинулся какой-нибудь книжкой-умной статьёй :)
Таки к забугорным людям. И конкретно протокол телеграмма.
(Конечно, куча проверок на доступности хостов и тд, тут сама идея описана)