Pull to refresh

Наглядно о потоке выполнения в Node.js

Node.JS *
В комментариях к моему предыдущему топику об асинхронном программировании, коллбеках и использовании process.NextTick() в Node.js было задано немало вопросов о том, за счёт чего получается или может быть получена большая производительность при использовании неблокирующего кода. Постараюсь это наглядно показать :) Статья призвана в основном прояснить некоторые моменты работы Node.js (и libeio в его составе), которые на словах бывает трудно описать.

Пример обработки запросов сервером с блокирующим чтением:


В первую очередь прокомментирую полезность использования неблокирующего ввода/вывода. Как правило, использовать блокирующие операции в Node.js стоит лишь на этапе инициализации приложения, и то не всегда. Правильная обработка ошибок в любом случае потребует использования try/catch, так что код при использовании неблокирующих операций не будет сложнее, чем при использовании блокирующих операций.
Нужно лишь помнить, что случае, когда запросов неблокирующих операций может оказаться больше, чем потоков libeio. В этом случае новые запросы будут становиться в очередь и блокировать выполнение, однако для программиста это будет происходить прозрачно.
Преимущества неблокирующих операций и некоторые недостатки в картинках
Total votes 43: ↑38 and ↓5 +33
Views 12K
Comments 22

Создание языка программирования с использованием LLVM. Часть 3: Генерация кода LLVM IR

Compilers *
Translation
Добро пожаловать в Главу 3 учебника «Создание языка программирования с LLVM». В этой главе мы рассмотрим, как преобразовать AST (Абстрактное Синтаксическое дерево), построенное в Главе 2, в LLVM IR. Она расскажет вам о некоторых аспектах работы LLVM, а также продемонстрирует, насколько он прост в использовании. Вы увидите, что гораздо больше труда потребовалось на лексический и синтаксический анализ, чем на непосредственное создание кода LLVM IR.

Обратите внимание: код из этой главы требует наличия LLVM 2.2 или более поздней версии. С версиями по LLVM 2.1 включительно этот код работать не будет. Также стоит отметить, что вам стоит использовать версию этого учебника, которая соответствует вашему релизу LLVM: вы можете использовать документацию, которая прилагается к официальным выпускам или посетить страницу с релизами на llvm.org.
Читать дальше →
Total votes 28: ↑26 and ↓2 +24
Views 14K
Comments 11

Создание языка программирования с использованием LLVM. Часть 5: Расширение языка: Поток управления

Compilers *
Translation
Добро пожаловать в Главу 5 учебника «Создание языка программирования с LLVM». Предыдущие главы (1-я, 2-я, 3-я и 4-я) описывали реализацию простого языка программирования Kaleidoscope и включение в него поддержки генерации LLVM IR, а также последующей оптимизации и JIT-компиляции. К сожалению, в текущем виде Kaleidoscope почти бесполезен: он не имеет никакого потока управления, за исключением вызовов и возвратов. Это означает, что в коде не может быть условных переходов, что значительно ограничивает язык программирования. В этой главе мы расширим Kaleidoscope, добавив в него выражение if/then/else и простой цикл "for".
Читать дальше →
Total votes 21: ↑19 and ↓2 +17
Views 6.8K
Comments 3

Абстрагирование потока управления

Python *Programming *Functional Programming *
Любой программист, даже если не смотрит на свою работу в таком ключе, постоянно занимается построением абстракций. Чаще всего мы абстрагируем вычисления (пишем функции) или поведение (процедуры и классы), но кроме этих двух случаев в нашей работе возникает множество повторяющихся шаблонов особенно при обработке ошибок, управлении ресурсами, написании стандартных обработчиков и оптимизаций.

Что значит абстрагирование потока управления или «control flow», как выражаются наши заморские друзья? В случае, когда никто не выпендривается, потоком занимаются управляющие конструкции. Иногда этих управляющих конструкций недостаточно и мы дописываем свои, абстрагирующие нужное нам поведение программы. Это просто в языках вроде lisp, ruby или perl, но и в других языках это возможно, например, с помощью функций высшего порядка.
Читать дальше →
Total votes 44: ↑40 and ↓4 +36
Views 14K
Comments 10

Не надо давать обещания, или Promises наоборот

JavaScript *Node.JS *
Sandbox
Каждый программист, начинающий разрабатывать под Node.js, встаёт перед выбором стратегии организации асинхронного кода в проекте. В то время, как в небольших системных утилитах поддерживать гигиену асинхронного кода достаточно просто, при росте массы кода в проекте решение этой задачи начинает требовать введения дополнительного, так называемого control flow средства.

В этой статье будет рассмотрена небольшая control flow библиотека «Flowy», являющаяся развитием идей проекта Step Тима Касвелла, и ядро которой базируется на концепциях CommonJS Promises, а также приведены аргументы, почему же Promises — это так неудобно.


Читать дальше →
Total votes 21: ↑16 and ↓5 +11
Views 9.2K
Comments 7

Неявные предикаты

Information Security *Cryptography *.NET *
Речь здесь пойдёт о некоторых аспектах компьютерной безопасности, связанных с запутыванием кода программы. Именно это мне было интересно в связи с разработкой обфускатора .NET приложений – программы для защиты .NET кода от взлома. Есть и другая – тёмная сторона: запутыванием кода очень интересуются разработчики вирусов и других нехороших штук, но нам они неинтересны.


Эмуляторы


Итак, Вы придумали супер алгоритм для запутывания кода программы. При декомпиляции код выглядит просто вырвиглазно и никто точно такое анализировать не будет. Казалось: победа! Но нет. Естественно обфусцированный код никто анализировать не будет… руками. Хакер поймёт как вы код запутывали и напишет «распутывалку». Если Ваш алгоритм был достаточно силён, то хакеру придётся писать собственный эмулятор, но и это не такая проблема как может показаться на первый взгляд – в сети есть доступные эмуляторы и даже специально написанные именно для целей взлома.

Из теории компьютерных наук известно, что не существует и никогда не будет существовать алгоритма, определяющего остановится ли программа или будет работать вечно – так называемая «проблема останова». Это гарантирует, что хакерский эмулятор, распутывающий обфусцированную программу, будет делать это как бы «локально»: он не сможет узнать состояние и значение всех переменных, задействованных в каждом участке кода и поэтому в точках условного ветвления часто будет полагать, что возможны все варианты хода программы. Вот тут-то на ум и приходит решение: запутанный код будет наполнен переходами по условиям, которые будут всегда истинны, но проэмулировать и понять это будет трудно. Примерно вот так:

if ((x+x & 1) == 0)
  good_code
else
  мусор


«Но это же как раз одна из тех запутывалок, которые хакер и собирается обходить с помощью эмулятора» — скажете Вы и будете правы. А что если придумать тысячу подобных фокусов? О, это решение, если у Вас есть легион программистов, каждый из которых придумывает трюки не похожие на трюки других. В реальности это не так. В реальности Вы думаете неделю и придумываете тридцать трюков, а хакер смотрит на код один день и находит все тридцать трюков, потому что тридцать – это не так уж много.

Читать дальше →
Total votes 39: ↑36 and ↓3 +33
Views 21K
Comments 31

Статический анализ IntelliJ IDEA против человеческого разума

JetBrains corporate blog Programming *Java *

Не так давно я изучал вывод статического анализатора IntelliJ IDEA для Java-кода и наткнулся на интересный случай. Так как соответствующий фрагмент кода не является open source, я его анонимизировал и отвязал от внешних зависимостей. Будем считать, что он выглядел так:


private static List<Integer> process(Map<String, Integer> options, List<String> inputs) {
    List<Integer> res = new ArrayList<>();
    int cur = -1;
    for (String str : inputs) {
        if (str.startsWith("-"))
            if (options.containsKey(str)) {
                if (cur == -1) cur = options.get(str);
            }
            else if (options.containsKey("+" + str)) {
                if (cur == -1) cur = res.isEmpty() ? -1 :
                        res.remove(res.size() - 1);
                if (cur != -1) res.add(cur + str.length());
            }
    }
    return res;
}

Код как код, что-то преобразуется, что-то делается, но статическому анализатору он не понравился. Здесь мы видим целых два предупреждения:


Code screenshot

Читать дальше →
Total votes 52: ↑51 and ↓1 +50
Views 12K
Comments 26

Введение в аппаратную защиту стека (Windows 10)

Information Security *System Programming *Development for Windows *Computer hardware
Translation

Под катом представлен перевод статьи "Understanding Hardware-enforced Stack Protection".


Авторы: Kernel protection team — Jin Lin, Jason Lin, Niraj Majmudar, Greg Colombo


Это первая (обзорная) публикация задуманной серии из двух переводов о внедрении Intel'овской Control-flow Enforcement Technology (CET) в Windows 10.

Читать дальше →
Total votes 12: ↑12 and ↓0 +12
Views 4.4K
Comments 5

Где логика?! История тестирования одного микросервиса

DINS corporate blog IT systems testing *Conferences

Эта статья — расшифровка доклада Дениса Кудряшова, QA-инженера Leroy Merlin, с конференции QA Meeting Point 2020.

Денис рассказал, как столкнулся со сложной логикой, реализованной в сервисе, применил подход Control Flow Testing, и что из этого вышло. Из текста вы узнаете, можно ли использовать этот подход для синхронных или для асинхронных логических схем, какие нюансы есть у каждого кейса, а также почему моки и Control Flow Testing — идеальное сочетание.

Читать далее
Total votes 9: ↑8 and ↓1 +7
Views 3.5K
Comments 1