«точка останова» очень слабо помогает в мультипоточной высококонкурентной среде, особенно если треды зеленые, и их — легион.
Именно этот сценарий с отладкой зеленых тредов меня и заставил задаться вопросами из статьи. :)
остановка выполнения просто больше не актуальна
По-моему, тут дело в том, что мы воспринимаем отладку как интерактивный процесс, хотя это не обязательно так и не всегда так. "Остановка выполнения" может занимать миллисекунды и происходить автоматически, незаметно для вас. В комментарии выше я приводил примеры с BPF, который по сути тоже является отладчиком и как раз помогает работать с такими сценариями, когда у нас миллионы событий, и среди них надо выцепить нужное и понять, что именно происходит. DTrace в FreeBSD/Solaris решает ту же проблему с помощью специального DSL, позволяющего эффективно фильтровать события, агрегировать их, и выводить нужный результат — и это гораздо удобнее тех же принтов, потому что а) программу не надо перекомпилировать, б) точки трассировки можно добавлять прямо в рантайме в любой процесс (в том числе в продакшене), со сравнительно небольшим оверхедом, в) точки трассировки можно добавлять даже в ядро.
Если смотреть с точки зрения Си, то, пожалуй, наиболее близкий пример здесь — это BPF, виртуальная машина внутри ядра Линукса, на базе которой, например, делают инструменты трассировки bcc. Через них можете смотреть, какие системные вызовы происходят, какие файлы открываются программой, сколько памяти выделяется (и отслеживать утечки), и т.д. — все это работает похожим на gdb образом, с той разницей, что брейкпоинты ставятся и обрабатываются "автоматически" — т.е., скажем, поставили брейкпоинт на вызов malloc(), и каждый раз, когда он дергается — считаем, сколько памяти выделили и откуда. В конце эту информацию суммируем и показываем пользователю.
Только в случае BPF это все обычно происходит в контексте ядра, а не в user space — но есть и версия BPF VM для юзерспейса, которая позволяет делать похожие штуки. То, что описывается в статье — близко по смыслу и духу к такому подходу, только в более общем направлении и с возможностью не только ставить брейкпоинты, но и читать произвольные области памяти. Как пример, можете посмотреть расширение для VS Code с визуализацией данных.
Да, это все можно делать, взаимодействуя с GDB через консоль или serial API, но это только та часть, которая про работу с процессами и памятью. Вторая же часть — символизация, которая в целом уже больше актуальна для Раста и других языков, т.к. в целом lldb работает в паре с clang и такой острой проблемы с тем же парсером выражений там нет.
Если говорить о конкретике, то текста получилось бы еще на пару экранов. :) Основная проблема — это отсутствие поддержки языковых фич, да хотя бы даже парсеров выражений. В lldb, например, для Раста вообще используется парсер выражений от C++, что вызывает серьезные трудности. Если пытаться отлаживать менее прямолинейный код (например, async/await в Расте или код использующий thread-local переменные в C/C++), все эти проблемы начинают копиться как снежный ком, и в итоге получается, что проще вернуться к знакомым println и логам.
Для C/C++ под Линукс чуть помогает rr, который умеет «отматывать» время назад. В WinDbg Preview тоже такое недавно добавили. Но это только часть необходимых возможностей, конечно.
К сожалению, работа и участие в развитии сообществ вносят свои коррективы в планы — увы, пока времени так и не нашлось, а требуется его на подобные статьи много.
К тому же, в данном случае нужно не продолжение, а переписывание почти с нуля, учитывая произошедшие изменения в компиляторе Rust и изменения в библиотеке mio. Пока рекомендую посмотреть в сторону Tokio — на данный момент это стандарт де-факто для программирования асинхронных штук в мире Раста. У них на сайте неплохие руководства, но, к сожалению, пока только на английском.
Как выйдет продолжение, я обязательно отвечу сюда и оповещу. Спасибо за мотивацию! :)
А при реальной разработке игр (на Unity и вообще) тоже используется такой подход, когда логика пишется отдельным, абстрактным модулем и потом подключается к игровому движку, или это просто пример для статьи?
Думаю, это просто с непривычки, вот и кажется сложным. Если язык как таковой вам интересен, делайте пробные приложения дальше, со временем в голове все встанет на свои места. По большому счету он не сложнее Си (и точно проще C++). Ну и присоединяйтесь к русскоязычному коммьюнити, поможем, чем сможем. :)
Не спорю, конструкция фразы не совсем удачная — подразумевалось скорее значительно превышающее разумные пределы кол-во тредов.
В этом плане 8000 — относительно небольшое число, потому что известная "проблема C10K" уже в далеком прошлом. Как себя в тех же условиях покажут, скажем, 100 тысяч потоков? А миллион? А 10 миллионов? :) Это более актуальные на сегодняшний день цифры.
Да, вы правы, про resize стоит поправить — метод уже давно стабилизован.
Во время написания текста и кода метод еще был помечен как unstable, поэтому и используется такое вот странное решение. :)
Различные примеры — такое возможно, исправлю.
Спасибо за отзыв!
в чем пишите код? Уже появились более-менее нормальные IDE, умеющие не только синтаксис подсвечивать?
Код пишу в Emacs. А нечто подобное IDE уже давно есть — например, в виде дополнения для редакторов/IDE, Racer, которое добавляет автодополнение кода и всякие другие удобства. Еще есть плагин для IntelliJ Idea, но я сам его не пробовал, честно говоря.
если уж программист решил изучать Rust, то скорее всего он знает английский хотя бы на уровне чтения техдокументации.
По-моему это неправильный образ мышления. Вот как раз потому что все думают, что все вокруг знают английский на русском так мало технических статей и документации. И поэтому в университетах люди до сих пор учат Pascal/C++, и ничего лучше этого и не знают. Я утрирую, конечно, но развивать русскоязычное сообщество однозначно полезно и нужно.
Я думаю что поддержка Windows в mio пока еще очень сырая. Но вообще для подобных вопросов у них существует канал в IRC — irc.mozilla.org/#mio.
Ну и, честно говоря, Windows при написании статьи я вообще не учитывал. Наверное, это плохо, но из моей практики серверы под Win — исчезающе редкое явление. Я бы на вашем месте экспериментировал в виртуальной машине с Linux'ом.
Для этого, кстати, достаточно разрешить атрибут id у заголовков (ну или атрибут name у тегов «a»). Сначала хотел сделать с оглавлением, но все якоря беспощадно вырезаются HTML-парсером Хабра.
запустить несколько потоков, в каждом запустить event loop, и диспетчеризировать подключения между ними в рамках одного процесса
Ну, на самом деле я именно так и планировал сделать и рассказать об этом в одной из следующих статей.
Полагаю, что вопрос cy-ernado касается самой теоретической возможности разброса event loop'ов на несколько ядер/процессоров — а с этой точки зрения, конечно, mio все умеет. :)
Именно этот сценарий с отладкой зеленых тредов меня и заставил задаться вопросами из статьи. :)
По-моему, тут дело в том, что мы воспринимаем отладку как интерактивный процесс, хотя это не обязательно так и не всегда так. "Остановка выполнения" может занимать миллисекунды и происходить автоматически, незаметно для вас. В комментарии выше я приводил примеры с BPF, который по сути тоже является отладчиком и как раз помогает работать с такими сценариями, когда у нас миллионы событий, и среди них надо выцепить нужное и понять, что именно происходит. DTrace в FreeBSD/Solaris решает ту же проблему с помощью специального DSL, позволяющего эффективно фильтровать события, агрегировать их, и выводить нужный результат — и это гораздо удобнее тех же принтов, потому что а) программу не надо перекомпилировать, б) точки трассировки можно добавлять прямо в рантайме в любой процесс (в том числе в продакшене), со сравнительно небольшим оверхедом, в) точки трассировки можно добавлять даже в ядро.
Если смотреть с точки зрения Си, то, пожалуй, наиболее близкий пример здесь — это BPF, виртуальная машина внутри ядра Линукса, на базе которой, например, делают инструменты трассировки bcc. Через них можете смотреть, какие системные вызовы происходят, какие файлы открываются программой, сколько памяти выделяется (и отслеживать утечки), и т.д. — все это работает похожим на gdb образом, с той разницей, что брейкпоинты ставятся и обрабатываются "автоматически" — т.е., скажем, поставили брейкпоинт на вызов
malloc(), и каждый раз, когда он дергается — считаем, сколько памяти выделили и откуда. В конце эту информацию суммируем и показываем пользователю.Только в случае BPF это все обычно происходит в контексте ядра, а не в user space — но есть и версия BPF VM для юзерспейса, которая позволяет делать похожие штуки. То, что описывается в статье — близко по смыслу и духу к такому подходу, только в более общем направлении и с возможностью не только ставить брейкпоинты, но и читать произвольные области памяти. Как пример, можете посмотреть расширение для VS Code с визуализацией данных.
Да, это все можно делать, взаимодействуя с GDB через консоль или serial API, но это только та часть, которая про работу с процессами и памятью. Вторая же часть — символизация, которая в целом уже больше актуальна для Раста и других языков, т.к. в целом lldb работает в паре с clang и такой острой проблемы с тем же парсером выражений там нет.
Если говорить о конкретике, то текста получилось бы еще на пару экранов. :) Основная проблема — это отсутствие поддержки языковых фич, да хотя бы даже парсеров выражений. В lldb, например, для Раста вообще используется парсер выражений от C++, что вызывает серьезные трудности. Если пытаться отлаживать менее прямолинейный код (например, async/await в Расте или код использующий thread-local переменные в C/C++), все эти проблемы начинают копиться как снежный ком, и в итоге получается, что проще вернуться к знакомым println и логам.
Для C/C++ под Линукс чуть помогает rr, который умеет «отматывать» время назад. В WinDbg Preview тоже такое недавно добавили. Но это только часть необходимых возможностей, конечно.
К сожалению, работа и участие в развитии сообществ вносят свои коррективы в планы — увы, пока времени так и не нашлось, а требуется его на подобные статьи много.
К тому же, в данном случае нужно не продолжение, а переписывание почти с нуля, учитывая произошедшие изменения в компиляторе Rust и изменения в библиотеке mio. Пока рекомендую посмотреть в сторону Tokio — на данный момент это стандарт де-факто для программирования асинхронных штук в мире Раста. У них на сайте неплохие руководства, но, к сожалению, пока только на английском.
Как выйдет продолжение, я обязательно отвечу сюда и оповещу. Спасибо за мотивацию! :)
Всегда начинаю писать тесты с
assert true.Это же стандартная практика — проверить, что сам тестировочный фреймворк работает, проект корректно настроен и нужные классы импортируются.
А при реальной разработке игр (на Unity и вообще) тоже используется такой подход, когда логика пишется отдельным, абстрактным модулем и потом подключается к игровому движку, или это просто пример для статьи?
Немного сырая IDE есть в виде плагина для IntelliJ Idea, вроде даже под патронажем JetBrains разрабатывают. Остальные варианты вот тут можете посмотреть: https://areweideyet.com/
Думаю, это просто с непривычки, вот и кажется сложным. Если язык как таковой вам интересен, делайте пробные приложения дальше, со временем в голове все встанет на свои места. По большому счету он не сложнее Си (и точно проще C++). Ну и присоединяйтесь к русскоязычному коммьюнити, поможем, чем сможем. :)
В этом плане 8000 — относительно небольшое число, потому что известная "проблема C10K" уже в далеком прошлом. Как себя в тех же условиях покажут, скажем, 100 тысяч потоков? А миллион? А 10 миллионов? :) Это более актуальные на сегодняшний день цифры.
Во время написания текста и кода метод еще был помечен как unstable, поэтому и используется такое вот странное решение. :)
Различные примеры — такое возможно, исправлю.
Спасибо за отзыв!
Код пишу в Emacs. А нечто подобное IDE уже давно есть — например, в виде дополнения для редакторов/IDE, Racer, которое добавляет автодополнение кода и всякие другие удобства. Еще есть плагин для IntelliJ Idea, но я сам его не пробовал, честно говоря.
Два:
Три:
Ну и, честно говоря, Windows при написании статьи я вообще не учитывал. Наверное, это плохо, но из моей практики серверы под Win — исчезающе редкое явление. Я бы на вашем месте экспериментировал в виртуальной машине с Linux'ом.
Еще раз спасибо, megaserg! :)
Полагаю, что вопрос cy-ernado касается самой теоретической возможности разброса event loop'ов на несколько ядер/процессоров — а с этой точки зрения, конечно, mio все умеет. :)