Всем привет. Подскажите, пожалуйста, какие аннотации в Java типа "Nullable"/"NonNull"/"NotNull" поймут котлин и андроид студия? Парочку проверил экспериментально, но хочется всё-таки увидеть список.

Как минимум, org.jetbrains.annotations и все на основе JSR-305 (http://kotlinlang.org/docs/reference/java-interop.html#jsr-305-support)

Как минимум, org.jetbrains.annotations и все на основе JSR-305 (http://kotlinlang.org/docs/reference/java-interop.html#jsr-305-support)

прям то, что нужно, спасибо

мне казалось, что котлиновские корутины - просто сахар над колбеками

квазар и котлиновские корутины - это конкурирующие технологии, которые по сути делают одно и тоже, просто разными способами

реактор тоже?

квазар и котлиновские корутины - это конкурирующие технологии, которые по сути делают одно и тоже, просто разными способами

так котлиновские корутины мне помогут инструментировать InputStream или нет?

так котлиновские корутины мне помогут инструментировать InputStream или нет?

инструментировать стандартный InputStream - нет но можно сделать асинхронный аналог InputStream и использовать его

асинхронный я и так могу сделать на колбеках

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

асинхронный я и так могу сделать на колбеках

можно, только это будет коряво

меня сейчас больше интересует производительность, чем красота

так котлиновские корутины мне помогут инструментировать InputStream или нет?

Нет. Котлиновские корутины работают через котлиновский компилятор

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

Кажется, нет: чтобы засуспендить выполнение функции, сгенерированный байт-код возвращает специальный объект, который все функции выше по стеку должны вернуть.

файберы кажется могут такое устроить

Нет адекватного способа вызвать suspend-функцию из не-suspend-функции, потому что последняя не умеет ни возвращать флаг суспенда, ни продолжать выполнение с произвольного места.

файберы кажется могут такое устроить

Файберы в Quasar вряд ли могут проинструментировать класс JDK

короче проще бросить всю затею с магией зеленых потоков

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

тут корутины не помогут они рассчитаны на котлиновский код, хакать существующие java библиотеки они не будут

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

xnio?

может, форкнуть библиотеку и убрать из неё всю некрофилию с InputStream?

https://github.com/andrewoma/coroutine-jdbc

xnio?

там есть что-то похожее?

https://github.com/andrewoma/coroutine-jdbc

но jdbc же блокирующее, как оно будет работать?

но jdbc же блокирующее, как оно будет работать?

создаст стопицот потоков и заблокирует их, а твой event loop будет свободен

И сожрёт 100500 * Xss оффхипа

создаст стопицот потоков и заблокирует их, а твой event loop будет свободен

так я свой тредпул могу юзать с блокирующим io, я хочу чтобы не блокировалось, чтобы потоков всего было по количеству ядер и никакого переключения контекста

так я свой тредпул могу юзать с блокирующим io, я хочу чтобы не блокировалось, чтобы потоков всего было по количеству ядер и никакого переключения контекста

да понятно, все мы хотим)

мб форкнуть JDBC?

Там же всё грозятся сделать асинхронный api в jdbc

так я свой тредпул могу юзать с блокирующим io, я хочу чтобы не блокировалось, чтобы потоков всего было по количеству ядер и никакого переключения контекста

А какая база?

postgres

Для постгри и мускуля вроде написаны асинхронные драва на nio

Там же всё грозятся сделать асинхронный api в jdbc

а будет апи, чтобы свою имплементацию nio прикрутить?

а будет апи, чтобы свою имплементацию nio прикрутить?

Эт я хз, они только грозились

Вот что то есть на джавке https://github.com/alaisi/postgres-async-driver

у вертекса есть шустренький драйвер постгреса

вот если там нетворк подменить на свой, то все будет зашибись

я не вижу особого смысла в асинхронности, если она выполняется в другом потоке

так же можно просто отдельный тред создать и юзать блокирующие вызовы

Ну по ресурсам это совсем не одно и тоже

Как ты собираешься в асинхронщины без смены потоков?

Как ты собираешься в асинхронщины без смены потоков?

м.. на колбеках, не вижу проблем

м.. на колбеках, не вижу проблем

А это не смена потока?

не обязательно

вот этот клиент немного щупал. корни уходят в vertx , nio https://github.com/reactiverse/reactive-pg-client Сама обертка вроде не создает потоки

А это не смена потока?

у меня есть nio, которое кидает эвенты на возможность чтения/записи в сокет, пришел реквест, я это прочитал, понял, что нужно сходить в базу, создал коннект в том же nio, кинул туда sql запрос, повесил колбек на ответ, ушел ждать эвентов в nio, получил эвент на чтение из базы, прочитал ответ, выполнил колбек и срендерил ответ, записал его в сокет изначального реквеста. Все в одном потоке

проблема только в блокирующем io на jdbc

вот этот клиент немного щупал. корни уходят в vertx , nio https://github.com/reactiverse/reactive-pg-client Сама обертка вроде не создает потоки

да, эта штука, нужно форкнуть и подменить реализацию io

а что с ней не так?

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

у меня даже апдейты не работали, только чтение

там nio, поддерживает unix domain sockets если postgres и app на одной машине

Это хорошо, но это довольно редкая ситуация, обычно база отдельно от приложения

даже если отдельно то там nio как ни крути

не излишне ли вообще поднимать СУБД в отдельном процессе, если всё на одной машине?

даже если отдельно то там nio как ни крути

У меня свой nio, писать запрос в другой nio - все равно что юзать блокирующий io

либа не создает потоки. Правда со всеми этими асинхронными драйверами (эта либа не единственная) я только не понимаю как в конечном итоге идет взаимодействие с postgres. postgres построен на процессах и shared memory, каждое соединение - это процесс. если вы создаете пул соединений к бд - то это пул процессов. в каждом процессе своя нить. Даже если в нашем приложении 1 поток, то в итоге все равно же будет переключение контекста

У меня свой nio, писать запрос в другой nio - все равно что юзать блокирующий io

не понимаю, можете разжевать?

А большой ли вообще смысл в асинхронном IO с СУБД, если сама СУБД может выполнять параллельно весьма ограниченное количество запросов?

не понимаю, можете разжевать?

У меня своя обёртка над линуксовым epoll, которая имплементит неблокирующее io

А большой ли вообще смысл в асинхронном IO с СУБД, если сама СУБД может выполнять параллельно весьма ограниченное количество запросов?

postgres вполне неплохо параллелится на многоядерных системах

У меня своя обёртка над линуксовым epoll, которая имплементит неблокирующее io

Я в этом вопросе могу плавать, так как не делал, но вроде как этой библиотеке можно скормить эту обертку, чтобы она через нее ходила

postgres вполне неплохо параллелится на многоядерных системах

Но ведь каждое соединение всё равно дорогое? По сравнению с этим держать в приложении заблокированный поток на это соединение не видится таким большим злом.

А большой ли вообще смысл в асинхронном IO с СУБД, если сама СУБД может выполнять параллельно весьма ограниченное количество запросов?

Кроме того, может быть подключение к нескольким субд, тот же jdbc поддерживает multiple endpoints

поправьте, если ошибаюсь, это то как я понимаю: В чем отличие jdbc от асинхронных драйверов в разрезе обсуждаемой темы. Если у вас app написан в блокирующем стиле, блокирующее io, например спринг и другие, то у вас поток на коннекшен есть, потом таска шедулится в поток пула, потом шедулится в процесс постгры. и обратно ответ идет также. Если у вас app написан в асинхронном стиле, технологии базирующиеся на nio - netty / jetty и прочие, соответственно тот же spring 5 webflux или KTOR, то минус поток на обработку коннекшена. Если и пул потоков будет асинхронным как в этой библиотеке, то еще минус 1 переключение контекста. Вот есть ли выигрыш в переключениях контекста, я не уверен. Так как синхронное io все равно производительней. Поэтому мне кажется, что решение использовать jdbc в пуле потоков или использовать асинхронные драйвера не будет базироваться на производительности из-за отсутствия переключения контекстов - скорее всего это не играет роли. Но например при использовании ktor c корутинами очень удобно было асинхронное API завернуть в suspend функцию. Это можно сделать и с синхронным jdbc + пул потоков.

поправьте, если ошибаюсь, это то как я понимаю: В чем отличие jdbc от асинхронных драйверов в разрезе обсуждаемой темы. Если у вас app написан в блокирующем стиле, блокирующее io, например спринг и другие, то у вас поток на коннекшен есть, потом таска шедулится в поток пула, потом шедулится в процесс постгры. и обратно ответ идет также. Если у вас app написан в асинхронном стиле, технологии базирующиеся на nio - netty / jetty и прочие, соответственно тот же spring 5 webflux или KTOR, то минус поток на обработку коннекшена. Если и пул потоков будет асинхронным как в этой библиотеке, то еще минус 1 переключение контекста. Вот есть ли выигрыш в переключениях контекста, я не уверен. Так как синхронное io все равно производительней. Поэтому мне кажется, что решение использовать jdbc в пуле потоков или использовать асинхронные драйвера не будет базироваться на производительности из-за отсутствия переключения контекстов - скорее всего это не играет роли. Но например при использовании ktor c корутинами очень удобно было асинхронное API завернуть в suspend функцию. Это можно сделать и с синхронным jdbc + пул потоков.

> синхронное io все равно производительней эмм, это где так и почему?

статьи были где сравнивалось nio и io. суть была в том, что io проценотов на 15 - 20 производительней. Сейчас поищу

nio 1 из 1.4 или 2 из 1.7?

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

Вообще, эта тема вроде как холиварная) из-за непонимания акцента, на котором делают бенчмарк те или иные тестеры. Ведь как это свеженький nio может быть медленней древнего io? )) (ссылку все еще ищу)

в io без бутылки не разобраться

так сходу и не напишешь банальное считывание строк с файла

в io без бутылки не разобраться

Нет ничего проще

поправьте, если ошибаюсь, это то как я понимаю: В чем отличие jdbc от асинхронных драйверов в разрезе обсуждаемой темы. Если у вас app написан в блокирующем стиле, блокирующее io, например спринг и другие, то у вас поток на коннекшен есть, потом таска шедулится в поток пула, потом шедулится в процесс постгры. и обратно ответ идет также. Если у вас app написан в асинхронном стиле, технологии базирующиеся на nio - netty / jetty и прочие, соответственно тот же spring 5 webflux или KTOR, то минус поток на обработку коннекшена. Если и пул потоков будет асинхронным как в этой библиотеке, то еще минус 1 переключение контекста. Вот есть ли выигрыш в переключениях контекста, я не уверен. Так как синхронное io все равно производительней. Поэтому мне кажется, что решение использовать jdbc в пуле потоков или использовать асинхронные драйвера не будет базироваться на производительности из-за отсутствия переключения контекстов - скорее всего это не играет роли. Но например при использовании ktor c корутинами очень удобно было асинхронное API завернуть в suspend функцию. Это можно сделать и с синхронным jdbc + пул потоков.

кроме nio vs io других отклонений от общего понимания как все работает нет?

nio 1 из 1.4 или 2 из 1.7?

дефолтный nio в жаве вообще не очень, насколько я помню, он не умеет в многопоточность

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

Это было конкретно про потоковое чтение

Что если у тебя есть готовый стрим, то его быстрее вычитать через io чем через колбеки с nio

Что если у тебя есть готовый стрим, то его быстрее вычитать через io чем через колбеки с nio

быстрее - в плане код проще написать?

Быстрее в плане по времени исполнения

реквестирую бенчмарки

https://github.com/romromov/java-io-benchmark

ну и, nio быстрее на буфере в 8кб, но медленнее на буфере в 1кб

серьезно, 1кб буфера? я меньше 16 нигде не юзаю

без "ну и"

просто результат

Там вся разница в буферизации и в том, сколько раз память дергается. nio тратить больше времени на один дерг, но при этом меньше на выкачивание большого буфера, так как он в общем случае аллоцируется вне кучи. Поэтому nio выигрывает на больших блоках данных, а io показывает лучшие результаты на коротких сообщениях.