pro.jvm

17 Dec 2024 09:39

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

мы же не пулим корутины или горутины

pro.jvm

17 Dec 2024 09:38

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

pro.jvm

17 Dec 2024 09:37

3 ляма я приводил в пример для сервака

pro.jvm

17 Dec 2024 09:37

Так это тысяча, не три миллиона

pro.jvm

17 Dec 2024 09:37

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

pro.jvm

17 Dec 2024 09:36

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

pro.jvm

17 Dec 2024 09:33

Я тоже, только сколько там запросов пройдет, и сколько ты будешь nic ждать?

pro.jvm

17 Dec 2024 09:33

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

pro.jvm

17 Dec 2024 09:32

без вирт тредов я как это сделаю?

pro.jvm

17 Dec 2024 09:32

и вирт треды которые в IO в бд висят просто будут спать

pro.jvm

17 Dec 2024 09:31

Я всё ещё не увидел зачем вам миллионы тредов, когда вы неизбежно упираетесь как минимум в контеншен
Почему ту кафку нельзя батчить последовательно относительно небольшим количеством тредов?

pro.jvm

17 Dec 2024 09:30

ага

It is possible, however, that code running in a virtual thread may require the use of a finite resource, such as a database connection.

pro.jvm

17 Dec 2024 09:29

Очередной спор на 400 сообщений

pro.jvm

17 Dec 2024 09:28

Раки по три тоже дешевые, но я их не покупаю по причине отсутствия необходимости

pro.jvm

17 Dec 2024 09:27

1. создание и уничтожение дешевое, размер стэка динамический
2. ими уже управляет платформенный пул трэдов

pro.jvm

17 Dec 2024 09:38

receive side scaling
нума ещё
нет-нет, не говори, что тебе не надо в общую память ходить

pro.jvm

17 Dec 2024 09:38

где именно? жава сама вирт треды по ядрам разрулит

pro.jvm

17 Dec 2024 09:37

И у тебя нет тысячи ядер, чтобы это было параллельно

pro.jvm

17 Dec 2024 09:37

так давно же есть оценка что реактивный подход даёт 15-30% к пропускной способности IO-intensive системы. Ну тоесть часто проще чуть больше железа докинуть зато всё будет проще и пограммистов подешевле можно будет взять, да и дебаг без реактивщины сильно упростится и ускорится.

pro.jvm

17 Dec 2024 09:36

576k циклов на запрос при 3ггц. Ты уверен, что ты уложишься? Как ты будешь делать RSS в джаве?

pro.jvm

17 Dec 2024 09:36

погоди, ты не понял задачу с кафкой

pro.jvm

17 Dec 2024 09:33

запросы по ним будут гонятсья

pro.jvm

17 Dec 2024 09:32

Так а зачем тебе создавать то, что тебе не нужно вообще в принципе?

pro.jvm

17 Dec 2024 09:32

Я тоже, только сколько там запросов пройдет, и сколько ты будешь nic ждать?

pro.jvm

17 Dec 2024 09:31

я могу себе позволить открыть лям коннектов к бд

pro.jvm

17 Dec 2024 09:31

НЕЕЕЕЕТ

ТЫ НЕ ДОЛЖЕН ЮЗАТЬ ВИРТУАЛЬНЫЕ ПОТОКИ

ВЫИГРЫША ПО ПАМЯТИ НЕТ

ЗАЧЕМ ТЕБЕ СОЗДАВАТЬ ИХ НА КАЖДЫЙ ЧИХ

ДАВАЙТЕ ПУЛИТЬ ВИРТУАЛЬНЫЕ ПОТОКИ

А ПЛАТФОРМЕННЫЕ ПОЧЕМУ ХАРАМ

pro.jvm

17 Dec 2024 09:29

тут один ноунейм ответил

pro.jvm

17 Dec 2024 09:29

https://stackoverflow.com/questions/77750151/should-virtual-thread-die-fast

pro.jvm

17 Dec 2024 09:28

Unlike platform thread stacks, virtual thread stacks are not GC roots. Thus the references they contain are not traversed in a stop-the-world pause by garbage collectors, such as G1, that perform concurrent heap scanning.

pro.jvm

17 Dec 2024 09:27

нет, я сегодня это читал про нативные

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