(сегодня = в 2020 году)

Хехехе

#ml-эксплоиты, теперь с ChatGPT, умеющей считывать картинки

Си плач плач

#prog #cpp #meme

После прохождения Half Life 2 наконец-то придумал продолжение для «Неуверенной России»

📷 Подписывайтесь на меня в соцсети «Инстаграм» и показывайте иностранным друзьям.

#prog #article #abnormalprogramming

Subtraction Is Functionally Complete (перевод)

To be precise, IEEE-754 floating point subtraction is functionally complete. That means you can construct any binary circuit using nothing but floating point subtraction.

(thanks @teamerlin)

Ну как обычно

Source

#prog #rust #rustasync #article

На этот раз — целая серия статей от Cliff L. Biffle. Все из них прямо или косвенно связаны с lilos — подходящая для встраиваемых систем операционная система реального времени, которая использует растовый async для запуска тасок (= приложений в этой OS) и потребляет очень мало ресурсов как в долговременной памяти, так и в оперативной:

This is a wee operating system written to support the async style of programming in Rust on microcontrollers. It fits in about 2 kiB of Flash and uses about 20 bytes of RAM (before your tasks are added). In that space, you get a full async runtime with multiple tasks, support for complex concurrency via join and select, and a lot of convenient but simple APIs.

lilos has been deployed in real embedded systems since 2019, running continuously. I've built about a dozen systems around it of varying complexity, on half a dozen varieties of microcontroller. It works pretty okay! Perhaps you will find it useful too.

Первая статья, которую я хочу затронуть — это How to think about `async`/`await` in Rust. В ней рассказывается о принципиальном отличии async fn от обычных функций — о том, что async fn суть машина состояний и потому в случае асинхронных функций контроль над исполнением кода имеет вызывающая сторона — а также немного о том, в какие практические следствия это вытекает.

Вторая статья: Composing concurrency in drivers (An example of why I like async for embedded). На примере наброска I2C-драйвера автор показывает, как можно добавить в код драйвера обработку ошибок и прерываний, не внося изменений в бизнес-логику протокола. Эта возможность весьма существенно полагается на особенности реализации async в Rust. Если быть более конкретным, итоговый код полагается на futures::select_biased!.

Как несложно догадаться, для корректной работы подобного кода исполняемые футуры должны быть cancel safe. Как сказано в документации к tokio::select!:

Cancellation safety can be defined in the following way: If you have a future that has not yet completed, then it must be a no-op to drop that future and recreate it. This definition is motivated by the situation where a select! is used in a loop. Without this guarantee, you would lose your progress when another branch completes and you restart the select! by going around the loop.

И cancellation safety обладает рядом крайне неприятных свойств:

* Она (или её отсутствие, что немаловажно) редко задокументирована.
* Cancellation unsafety заразительна: если футура не является cancel safe, то поверх неё невозможно сделать cancel safe обёртку.
* Cancellation safety (в отличие от weak exception safety) не композируется: можно взять два куска асинхронного кода, каждый из которых по отдельности cancel safe, и совместить их так, что получится cancel unsafe код.
* Так как cancellation safety является довольно сложным семантическим свойством (и, как справедливо замечают в документации tokio, cancel unsafe код — это не всегда что-то плохое), cancellation safety никак не отслеживается компилятором.

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

Имеющуюся плачевную ситуацию можно до какой-то степени улучшить, предоставив набор документированных cancel safe примитивных операций. И вот тут lilos заметно отличается от прочих асинк-экосистем. В статье с провокационным названием Mutex without lock, Queue without push: cancel safety in lilos автор рассказывает, как он смог сделать API в lilos cancel safe, причём в более строгом смысле, чем обычно. Именно, автор вводит несколько уровней cancellaton safety:

1. Cancel-unsafe — никакого вменяемого поведения при дропе, считай, unspecified behavior.
2. Strictly cancel-safe — удовлетворяет определению cancel safety из документации tokio выше, операция или происходит полностью, или не происходит вовсе при дропе футуры.
3. Weakly cancel-safe — дроп футуры не является noop, но, по крайней мере, эффект дропа полностью задокументирован.
4. Vacuously cancel-safe — код, который технически является cancel safe, но поощряет написание cancel unsafe кода. Как пишет автор: "These APIs are bug generators!".

Как автор выяснил (в частности, на собственных шишках), асинхронная операция push на очереди является weakly cancel safe, а операция взятия блокировки мьютекса — vacuously cancel-safe. В статье он предлагает cancel-safe альтернативу этим API, которые в итоге и были реализованы в последующих версиях lilos.

В несколько более техничной статье Writing a basic `async` debugger автор рассказывает о lildb — разработанным им инструменте, который позволяет неинтрузивно снимать с состояния программы await-trace-ы: именно, пути через код от корневых async-функций к листовым. Это позволяет помочь с ответами на вопросы в духе "почему эта часть асинхронного кода не исполняется". Существующие отладчики плохо подходят для подобных разбирательств, поскольку футуры в промежутках между вызовами poll — это просто структуры данных, у которых отсутствует стек. TL;DR: костыли.

В ещё более техничном продолжении Getting file/line in await traces автор рассказывает о том, как он смог сделать await-trace-ы более информативным за счёт указания на место в исходниках, в которых футуры остановились. TL;DR: больше костылей.

— Ты играешь в World of Tanks?
— Нет, я предпочитаю другие игры с танками.

Игры с танками:

#meme про работу