Перед вами четвёртый материал о разработке REST-серверов на Go. Здесь мы поговорим о том, как можно воспользоваться OpenAPI и Swagger для реализации стандартизированного подхода к описанию REST API, и о том, как генерировать Go-код на основе спецификации OpenAPI.

Сегодня, в третьей части серии материалов, посвящённых разработке серверов на Go, мы займёмся реализацией нашего REST-сервера с использованием Gin — одного из самых популярных веб-фреймворков для Go. Вот код, который мы будем тут обсуждать.

Перед вами второй материал из серии статей, посвящённой разработке REST-серверов на Go. В первом материале этой серии мы создали простой сервер, пользуясь стандартными средствами Go, а после этого отрефакторили код формирования JSON-данных, вынеся его во вспомогательную функцию. Это позволило нам выйти на достаточно компактный код обработчиков маршрутов.


Там мы говорили об одной проблеме нашего сервера, которая заключается в том, что логика маршрутизации разбросана по нескольким местам нашей программы.



Это — проблема, с которой сталкиваются все, кто пишет HTTP-сервера, не используя зависимости. Если только сервер, принимая во внимание систему его маршрутов, не является до крайности минималистичной конструкцией (например — это некоторые специализированные серверы, имеющие лишь один-два маршрута), то оказывается, что размеры и сложность организации кода маршрутизатора — это нечто такое, на что очень быстро обращают внимание опытные программисты.

Это — первый материал из серии статей, посвящённой разработке REST-серверов на Go. В этих статьях я планирую описать реализацию простого REST-сервера с использованием нескольких различных подходов. В результате эти подходы можно будет сравнить друг с другом, можно будет понять их относительные преимущества друг перед другом.

Первый вопрос разработчиков, которые только начинают применять Go, часто выглядит так: «Какой фреймворк стоит использовать для решения задачи X». И хотя это — совершенно нормальный вопрос, если задавать его, имея в виду веб-приложения и серверы, написанные на многих других языках, в случае с Go при ответе на этот вопрос нужно принять во внимание множество тонкостей. Существуют серьёзные аргументы как «за», так и «против» использования фреймворков в Go-проектах. Я, работая над статьями из этой серии, вижу своей целью объективное разностороннее исследование этого вопроса.

В прошлый раз мы остановились на том, что создали интерпретатор CHIP-8 и оснастили его системой для формирования кадров. Видеть то, что должно попасть на экран, можно в консоли. Теперь же мы собираемся взять то, что формирует интерпретатор, вынести это за пределы консоли и показать на экране.

Решать вышеозначенные задачи мы будем с помощью библиотеки SDL, которая умеет выводить графические данные на экран, принимать то, что вводит пользователь, и проигрывать звуки. Настройка SDL-проекта может вызвать некоторые сложности. Поэтому я рекомендую перед началом работы с библиотекой почитать мой материал о ней.



Есть много способов вывести что-либо на экран с использованием SDL. В играх, в основном, изображения не формируются, как в нашем случае, средствами CPU. Но при эмуляции и (что встречается чаще) при воспроизведении видео изображение (вполне возможно — сжатое) готовится к выводу средствами CPU. Такое изображение, для вывода его на экране, нужно загрузить в GPU. После того, как изображение попадёт в GPU, мы называем его «текстурой», а весь этот процесс называют «стримингом текстур».

Мы уже создали вполне рабочий эмулятор CHIP-8, но он, к сожалению, получился очень медленным. Почему? Если заглянуть в его главный цикл — можно увидеть, что данные на экран выводятся после выполнения каждого шага цикла. При включённом vsync SDL пытается привязать скорость рендеринга к частоте обновления кадров дисплея (возможно это — 60 Гц). Для нас это означает то, что метод SDLViewer::Update, почти при каждом его вызове, долго будет находиться в заблокированном состоянии, ожидая сигнала vsync от монитора.



Насколько быстро должен работать наш эмулятор? Точный ответ на этот вопрос дать не так уж и просто. На реальном компьютере на выполнение операций с разными кодами нужно разное время, но известны ориентировочные временные показатели выполнения различных операций. Можно выполнить инструкцию, выяснить то, сколько времени её выполнение должно занимать на реальном аппаратном обеспечении, а после этого «усыпить» программу до того момента, когда можно будет продолжать работу. Но тут есть одна проблема, которая заключается в том, что у нас, при таком подходе, нет доступа к временным параметрам работы CPU. На выполнение большинства этих инструкций должна уходить пара микросекунд, но на современных системах «усыплять» программы можно, как минимум, на одну миллисекунду.

Недавно мы опубликовали перевод первого материала из серии статей, посвящённой эмуляции компьютера. Автор этих статей подробно рассказывает о написании интерпретатора CHIP-8 на C++. В той публикации мы устроили опрос о целесообразности перевода продолжения цикла. Почти 94% тех, кто принял участие в опросе, продолжение перевода поддержали. Поэтому сегодня мы представляем вашему вниманию второй материал о CHIP-8.

Меня, по ряду причин, всегда завораживала эмуляция. Программа, которая выполняет другую программу… Мне эта идея кажется невероятно привлекательной. И у меня такое ощущение, что тот, кто напишет подобную программу, не пожалеет ни об одной минуте потраченного на это времени. Кроме того, написание эмулятора — это очень похоже на создание настоящего компьютера программными средствами. Мне было очень интересно разбираться в устройстве компьютерной архитектуры, писать простой HDL-код, но эмуляция — это гораздо более простой способ ощутить себя тем, кто своими руками создаёт компьютер. А ещё, в детстве, когда я впервые увидел игру Super Mario World, я поставил себе цель, которая до сих пор не потеряла для меня ценности. Она заключается в том, чтобы полностью понять то, как именно работает эта игра. Именно поэтому я уже некоторое время подумываю о написании эмулятора SNES/SNC. Недавно я решил, что пришло время сделать первый шаг к этой цели.

Предлагаю поговорить о разработке эмулятора и обсудить простой, но полноценный пример эмуляции CHIP-8.

Это — последний материал из серии четырёх статей (часть 1, часть 2, часть 3), посвящённой реализации epoll. Тут речь пойдёт о том, как epoll передаёт события из пространства ядра в пользовательское пространство, и о том, как реализованы режимы срабатывания по фронту и по уровню.



Эта статья написана позже остальных. Когда я начинал работу над первым материалом, самой свежей стабильной версией ядра Linux была 3.16.1. А во время написания данной статьи это уже версия 4.1. Именно на коде этой версии ядра и основана данная статья. Код, правда, изменился не особенно сильно, поэтому читатели предыдущих статей могут не беспокоиться о том, что что-то в реализации epoll очень сильно изменилось.

В предыдущих двух материалах (часть 1, часть 2) этой серии речь шла об общих вопросах работы epoll, и о том, как epoll получает уведомления о новых событиях от файловых дескрипторов, за которыми наблюдает. Здесь я расскажу о том, как epoll хранит уведомления о событиях, и о том, как эти уведомления получают приложения, работающие в пользовательском режиме.

Публикуя перевод первой статьи из цикла материалов о реализации epoll, мы провели опрос, посвящённый целесообразности перевода продолжения цикла. Более 90% участников опроса высказались за перевод остальных статей. Поэтому сегодня мы публикуем перевод второго материала из этого цикла.

Сегодня мы публикуем перевод первой статьи из серии материалов, посвящённых реализации epoll в ядре Linux 3.16.1*. Автор исходит из предположения о том, что читатели знакомы с API и с использованием epoll. Он уделяет основное внимание реализации подсистемы epoll в ядре Linux, а не особенностям её применения. Если вы не знаете о том, как пользоваться epoll — автор рекомендует сначала почитать документацию. Это значительно облегчит понимание деталей реализации этого механизма.



* — Linux 3.16.1 достаточно старое ядро, но информация работы с epoll актуальна и сегодня (прим. переводчика).