я в геймдеве юзал, нормалек

яв джаве ивент бейзд ИО поддерживает мультитридинг, почему не заюзать?

это где?

яв джаве ивент бейзд ИО поддерживает мультитридинг, почему не заюзать?

нужна же причина для того чтобы его юзать?

AsynchronousChannelGroup

нужна же причина для того чтобы его юзать?

это воркреры которые обрабатывают ИО ивенты, не вижу смысла лимитироваться на 1 потоке

это воркреры которые обрабатывают ИО ивенты, не вижу смысла лимитироваться на 1 потоке

вопрос не в лимтировании потока, а в максимальной его утилизации, vertx реализует евент-луп, который максимально утилизирует поток при нио-задачах.

вопрос не в лимтировании потока, а в максимальной его утилизации, vertx реализует евент-луп, который максимально утилизирует поток при нио-задачах.

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

советую поиграться с NIO.2 конкретно, тогда понятнее станет

там отличное ивент бейзд АПИ

Vert.x тоже не ограничен одним потоком

с многопоточностью

Vert.x тоже не ограничен одним потоком

мб потому что юзается НИО.2?

тут дело не в том, на чем оно работает внутри

а в идеологии

так что скажете сколько потоков в томкате ставить по какой формуле считать?

а то в нио кудато пошли)

это воркреры которые обрабатывают ИО ивенты, не вижу смысла лимитироваться на 1 потоке

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

Никогда бы не подумал что у меня будут проблемы с java, но есть: Component rootComponent = designContext.getRootComponent(); if(rootComponent instanceof PrintForm) { PrintForm rootComponent1 = (PrintForm) rootComponent; this.planPhase = rootComponent1.planPhase; }

Не обращайте внимание на код это прототип идеи

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

посмотри на select() и epoll(), вот те кецсы когда epoll() лучше

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

так вот planPhase в designContext.getRootComponent() это не null

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

никогда прежде я такого не видел

что тут происходит вообще?

посмотри на select() и epoll(), вот те кецсы когда epoll() лучше

я прекрасно осведомлен и о select() и о epoll(), что дальше?

Никогда бы не подумал что у меня будут проблемы с java, но есть: Component rootComponent = designContext.getRootComponent(); if(rootComponent instanceof PrintForm) { PrintForm rootComponent1 = (PrintForm) rootComponent; this.planPhase = rootComponent1.planPhase; }

ето что фактори?

нет, это наследование, и мы по сути получаем с помощью одного метода потомка

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

по конкретней? Ты предлагаешь откзаться от концепции Io потоков и потоков бизнес логики?

я прекрасно осведомлен и о select() и о epoll(), что дальше?

ну вот, epoll() отлично себя чувствует в многопоточной среде, и если у тебя дофига ИО и есть какая-то бизнес логика ,я буду в этом случае юзать больше чем 1 ИО воркер

и пытаемся вернуть значения в родителя потому что Design.read(path, this); пашет очень странно и не сетит значения в родителя

и кажется я наткнулся вот на причину того почему он не сетит

ну вот, epoll() отлично себя чувствует в многопоточной среде, и если у тебя дофига ИО и есть какая-то бизнес логика ,я буду в этом случае юзать больше чем 1 ИО воркер

а смысл от этого? Зачем запросы которые ты не можешь обработать?

а смысл от этого? Зачем запросы которые ты не можешь обработать?

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

поток не блокируется на перекладывании байтов

поток не блокируетя до отправки байтов по сети, но вполне этот поток копает эти байты в нужное место в ОС

на отправку

и копает из нужного места ОС на чтение

что за магия?

и копает из нужного места ОС на чтение

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

на этом поток говорит до свиданья и уходит

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

и кто же в системе это "выполняет"?

этим занимается система у которой есть свои процессы

но не твое приложение

этим занимается система у которой есть свои процессы

и твое приложение sys calls не делает?

разумеется, через системные вызовы и происходит общение с системой

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

а кто кстате занимается подготовкой буффера к отправке?

бизнес трид или ИО?

еще хочу заметить у сокета есть свой отдельный ресив/сенд буффер

а еще кто-то должен с ними работать

а байт буффер в котоый все ложится, это промежуточный этап

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

у тебя есть участок памяти, даже пускай в процессе jvm

а ты умеешь уже из одного процесса читать память другого?

покажешь как?

что ты несешь

я что ли говорил что умею читать?

ну так кто эти буфера обрабатывает если не ИО поток?

ну так кто эти буфера обрабатывает если не ИО поток?

что ты имеешь в виду под обрабатывает

копание данных из него и в него из нейтив буфферов сокета?

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

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

эм...

короче я устал спорить)

ERROR: S client not available

да не спорьте

ответьте на мой вопрос

если много бизнес логики, то одного IO потока достаточно, вывод спора таков

если много бизнес логики, то одного IO потока достаточно, вывод спора таков

и я с ним не согласен

это определяться по хорошему должно профилем нагрузки

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

в случае ноды, у них есть отдельные триды для бизнес логики?

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

в случае ноды, у них есть отдельные триды для бизнес логики?

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

воркеры это отделные процессы

это совсем не то)

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

как правило сейчас приложения не делают ничего вычислительно сложного

большинство***

поэтому одного потока и достаточно

ну так юзай там спринг на нетти

и все

где юзать

там где хотел ноду )

я и не хотел нигде ничего брать

я к тому что у нас на джаве доступны всек возможные варики

на ноде ты прибит гвоздями к их схеме )

на ноде ты прибит гвоздями к их схеме )

можно подробнее?

ну любое распаралеливание у тебя же только через процессы, не?

нода для меня - это вообще ацкий ад

там где хотел ноду )

нет же, нода куда более удобная штука. один асинк авейт чего стоит

нет же, нода куда более удобная штука. один асинк авейт чего стоит

ну тебе виднее, я пожалуй буду избегать джс дальше )

ну тебе виднее, я пожалуй буду избегать джс дальше )

ну сам js как язык да... боль, странностей хватает, но если сосредоточится именно на решении опеределённых задач, то удобство рантайма и экосистемы перевешывает косяки синтаксиса, имхо

ну сам js как язык да... боль, странностей хватает, но если сосредоточится именно на решении опеределённых задач, то удобство рантайма и экосистемы перевешывает косяки синтаксиса, имхо

я не вижу никаких не удобств на джава стеках )

а можно пару прям самых удобных удобств

а можно пару прям самых удобных удобств

нейкий асинк