Асинхронный ввод/вывод средствами операционной системы

P. S. cast stevejobs

Заводить фоновый поток исполнения (хоть managed, хоть native – неважно) не требуется

А event loop где крутится?

Краткая инфа по состоянию AIO в ляликсе https://lwn.net/Articles/671649/

А event loop где крутится?

В том-то и дело, что нигде. Фоновые потоки не создаются.

У тебя на руках – отложенное вычисление (это Task<T>, Future<T> или Deferred<T>), но задачу по выполнению этого вычисления берёт на себя ОС.

Ну либо ты сам можешь передать в метод callback, который будет выполнен по окончании вычисления, и который сможет принять и обработать результат этого вычисления.

В упомянутых мной низкоуровневых API, в общем-то, используется та же самая обстракция.

/me пошел по classpath и уткнулся в

/**
 * "Portable" implementation of AsynchronousFileChannel for use on operating
 * systems that don't support asynchronous file I/O.
 */

public class SimpleAsynchronousFileChannelImpl
    extends AsynchronousFileChannelImpl
{ ... }

* Смотреть комментарий

/me удивился, пошел в гугл и нагуглил по словам «AsynchronousFileChannel SimpleAsynchronousFileChannelImpl» это:

https://stackoverflow.com/questions/3955250/why-filechannel-in-java-is-not-non-blocking

А теперь разрешаю смеяться.

Спасибо.

Про sun.nio.ch.WindowsAsynchronousFileChannelImpl не знал, посмотрю. Что характерно, он реализует интерфейс Iocp.OverlappedChannel.

Ну и за статью тоже спасибо. Но статья всё-таки про неблокирующий ввод/вывод (non-blocking I/O), а мой вопрос про асинхронный (AIO). Это две разные вещи.

Кстати, тж показательно вот это обсуждение восьмилетней давности: Real async file IO on Linux?

Ты не путаешь файлы с сокетами? Если ты на диск отправишь миллион запросов, то он у тебя в любом случае будет ждать. Оптимальная скорость работы со средним SSD это около 32 потоков. Больше - смысла нет. Если у тебя хитрый рейд, можно больше, но всё равно не намного. Да и то тестить надо. С HDD скорей всего намного меньше будет. А сокеты жава нормально реализует. Не надо упарываться в асинхронность на каждый чих. Где-то это имеет смысл, где-то нет.

Это две разные вещи

Можешь это обосновать?

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

Мне кажется, ты че-то попутал. Пул потоков создается и ждёт запросы, они приходят и раскидываются по тредам этого пула, без создания треда на каждый запрос. А в дотнет можно без отдельных потоков в одном потоке крутить евентлуп и в нём асинхронно создавать таски по обслуживанию входящего соединения. Как в дотнет делается также и в libuv, и в node.js, libevent, asyncio; но поизводительность такого решения будет меньше, нежели с отдельным пулом потоков, которые запущены и ждут обработку запроса; как они ждут - через семафоры или событиями event loop - я не в курсе.

Netty смотрел?

лорчую этот коммент.

вне зависимости от реализации, винт не резиновый. и всё упирается в скорость IO.

Так проблема не в скорости записи на диск, а в том, что эта операция блочит потоки

обычно медленные IO выносят в отдельный поток.

Обычно использую нормальные технологии, в котором IO неблокирующий из коробки, тот же дотнет, жс или го, а не вручную какие-то отдельные потоки создают.

Какие-то потоки зачастую создать проще, чем всю программу переводить на коллбеки. В go просто создали абстракции, поэтому всё так «просто» кажется, в конечном счёте всё-равно приходится возиться то с каналами, то с async-await, то с синхронизациями и семафорами, на хелло вордах всё просто, а на деле везде свои плюсы - минусы есть. В том же libuv и go всё-равно под капотом создаются потоки под ввода-вывода.

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

В го можно планировщику прикреплять рутину к определенному треду, что, в принципе, почти эквивалентно созданию треда ручками в жаве. Но это очень редкий кейс и для ввода-вывода этого никто не делает, потому, что весь ввод-вывод в го асинхронный, реализованный через epoll, kqueue и aio на соответствующих платформах.

То что ты хочешь будет через год по-умолчанию, сейчас реализацией файберов занимается Project Loom. Уже есть готовый прототип, но заюзать его в продакшен-реди JDK ты не сможешь, только в тестовых билдах.

По сабжу с твоим task<T>, наверняка всё это уже реализовано в Spring. Погугли по «Spring Project Reactor AsynchronousFileChannel» или что-то такое.

По мне так вся эта асинхронщина - зло, поэтому по памяти кусок кода на Реакторе не напишу, а если разбираться - ну ты лучше меня это сделаешь, лол.

Олсо, я почти перестал заглядывать на ЛОР, т.к. считаю что администрация решила окончательно угробить ресурс, а как говорит эпиграф Арни Мишо к фильму «Мертвец» с Джонни Деппом, «Желательно не путешествовать с мертвецом». Прости за задержку с ответом, короче.

Стиви, администрация гробит ресурс с 1998 года, успокойся.

Погляди на talks. Там могильник, жопновзрывающих тем нет, даже на hackernews и то веселее. А был период, когда в толксах было весело, треш угар и содомия. Так что они не то чтобы его «гробят», а угробили окончательно.

Спасибо, Олег.

За «Мертвеца» плюс тебе в карму =)

Это просто ты стал старым и тебя уже ничего не задевает.

Ну почему же не задевает. Непрерывный срач на Хабре задевает, люблю его (написал статью про Котлин). Непрерывный срач в фейсбуке задевает (пару дней назад написал, почему мы в России всегда будем жить плохо, там в комментариях прям пир духа - раз, два. И такое постоянно!). Обличения, взаимное кидание говном друг в друга в фоллоуап-постах, обещания подать в суд за экстримизм, пиздюли IRL, проваленное собеседование - в общем, огонь, всё как я люблю. В толксах это всё было, но несколько лет назад. Современный состав модераторов-аутистов неспособен на настоящий огонь. Нужно чтобы у участников тредов жопы горели и взрывались, а это совершенно специальный майндсет.