Персистентная ОС: ничто не блокируется

… А еще можно сделать модную нынче стейтлесс асинхронность.
Хочешь прочитать кусок файла — сделай read (да чего уж там, сразу get) запрос по ури вида /path/to/file?start=xxx&len=yyy и жди ответа асинхронно (внутре либы это не обязательно делать через колбэки; epoll рулит тащемта и в смысле организации кода по типу горутин, и в смысле производительности).
При воскрешении снэпшота запрос read/get запрос тупо повторяется, если он не был завершен в прошлый раз. И да, write (put) и delete — тоже идемпотентные, т.е. их можно повторять. Проблемы — только с new (post). Но для таких вещей — транзакции.
На выходе получаем систему, в которой работающие треды можно прозрачно перебрасывать между серверами например, для балансировки нагрузки, отказоустойчивости и всего такого.
Ну это так, мысли в слух.

Такие мысли меня тоже посещают.

Старый добрый Fluke с неблокирующимися системными вызовами: https://www.usenix.org/legacy/events/osdi99/full_papers/lepreau/lepreau.pdf, плюс еще и ядерных стеков не надо.

Немного не в тему, но меня давно мучает вопрос про таймауты. Как организуется с ними работа в Фантоме. К примеру, я делаю чтение с жесткого диска. После запроса данных с жёсткого диска, но до их полного получения машина засыпает. Допустим, после пробуждения, стейтлесс асинхронность и транзакции позлят продолжить чтение файла с того места где программа остановилась. С точки зрения программы прошли доли секунды (вернее, несколько инструкций процессора), но если взять таймаут как разницу времени, то он может оказаться достаточно большим, чтобы решить, что в процессе чтения данных есть проблемы.
Как предполагается отличать проблемный (долгий) таймаут, от таймаута выспавшейся программы?

Просто коментарий: не лучше ли было на прикладном уровне реализовать принцип «let it fault»? То есть сделать некое подобие контекста транзакции для доступа к системным ресурсам (ядру). Вне контекста ресурсы недоступны. При изменении ядра или перезапуске системы данные программы восстанавливаются, однако ресурсы, задействованные транзакцией, становатся невалидными и при следующем доступе по хендлу генерируют исключение. Вся транзакция откатывается на момент начала и прозрачно рестартует: снова запрашиваются ресурсы и выполняются необходимые операции.

По-моему, весь этот геморрой связан исключительно с тем, что формирование снапшотов и вызовы в ядро могут пересекаться по времени. Как будто бы, корень проблемы именно в этом. Но неужели это так уж необходимо? Можно было бы делать все системные вызовы таким образом, чтобы они не сразу выполнялись, а сначала происходила проверка «далеко ли до следующего снапшота?» Если следующий снапшот ещё не скоро, то вызов уходит в ядро и к моменту снапшота уже успевает вернуться. Если же следующий снапшот уже идёт или вот-вот начнётся, то системный вызов просто шедулится на время «сразу после снапшота». Думаю, все и так понимают, что системные вызовы — это такая вещь, которая быстро не делается. Ну, подумаешь, придётся программе несколько лишних миллисекунд подождать в том случае, если она сделала свой вызов в неудачное для системы время. Это не смертельно.