Здравствуйте, mrTwister, Вы писали:
T> ·>Нет, такого добра уже везде как грязи. Горутины это специальная модель асинхронного взаимодействия — где у тебя есть специально помеченный в ЯП кусок кода и определённый механизм взаимодействия — каналы и посылка сообщений, тоже со своими ключевыми словами в ЯП и специальным магическим синтаксисом. И оно никак не стыкуется с классическими механизмами типа локов, хотя они тоже есть в go.
T> Откуда ты это взял? В go вытесняющая многозадачность, переключение горутины происходит даже если она крутит пустой цикл.
As I have mentioned in the last paragraph, Goroutines are cooperatively scheduled. In cooperative scheduling there is no concept of scheduler time slice. In such scheduling Goroutines yield the control periodically when they are idle or logically blocked in order to run multiple Goroutines concurrently. The switch between Goroutines happen only at well defined points — when an explicit call is made to the Goruntime scheduler. And those well defined points are:
Channels send and receive operations, if those operations would block.
The Go statement, although there is no guarantee that the new Goroutine will be scheduled immediately.
Blocking syscalls like file and network operations.
After being stopped for a garbage collection cycle.
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>> ·>Чтобы можно было писать простой код и запускать его на миллионе тредов. Никакой колбасы async, корутин и других CPS ужасов. Обычный плоский код. S>> Еще раз для упертых. виртуальные потоки это одна сотая от всех Тасков. Там в первую очередь TaskCompletionSource, а не IO причем внутри они могут вызывать друг друга. ·>Отлично, ты наконец-то стал что-то подозревать. Таски это аналог Future, который в java уже очень давно. Сабж — про другое.
Я тебе привел ограничения твоих виртуальных потоков по сравнению с нормальными тасками. Только и всего
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, m2user, Вы писали:
А> ·>Т.е. какой-то универсальный cancellation не нужен. А> Таймаут выбирается исходя из условий задачи (удаленность сервера в сети и т.п.). А> Закрытие сокета не всегда годится. Что если мне нужно прервать конкретную IO операцио, а потом продолжить работу с сокетом.
Это уже как-то сложно и наворочено получается. Скажем, работает у тебя операция чтения в массив размером в 100 мегабайт. Половину вычиталось из сокета, и тут пришел сигнал на отмену. Что с этим делать? Вкачать выкачанное обратно в интернет?
Так что разумный вариант — закрывать сокет, прерывать чтение исключением. Что interrupt в сабже и делает, если я не ошибаюсь.
А> Это все плохие решения, к которым приходится прибегать, если API не оставляет других вариантов.
Если не заниматься усложнизмом, то всё ок.
А> non-blocking I/O можно прервать через Thread.interrupt, но у этого флага весьма специфическое поведение: clearance.
Согласен, что interrupt очень по-странному реализован... Но, я надесь, простительно, ибо это было сделано с первой версии...
А> Как учесть это в стороннем коде, мне не ясно.
Это как бы баги"особенности" конкретного кода. Никто не запретит "особым" образом обрабатывать CancellationToken (если вообще ты как-то умудришься его протащить внутрь сторонней либы логгирования).
А> Из чего я делаю вывод, что cancellation для IO/CPU-bound задач нужно реализовать иным способ — добавлять перегруженные методы c аналогом CancellationToken, либо использовать Future. А> При работе с IO/CPU-bound кодом надежный cancellation для меня даже более критичен, чем потенциальный расход ресурсов на тяжеловесные потоки.
Честно говоря, не очень понимаю юзкейсы этого. Зачем надо всё делать отменяемым?
Насколько часто такое надо делать? Потому что если это какие-то corner cases, там это можно реализовать вручную, а не протаскивать везде и всюду.
А> Поэтому я не согласен с аргументом о том, что virtual threads позволят избежать необходимости перегрузки (или реализации через Future) существущих синхронных методов типа readAllBytes.
Не знаю насколько это необходимо, но это ортогонально virtual threads. Добавят, так добавят.
Здравствуйте, Serginio1, Вы писали:
S> ·>Отлично, ты наконец-то стал что-то подозревать. Таски это аналог Future, который в java уже очень давно. Сабж — про другое. S> Я тебе привел ограничения твоих виртуальных потоков по сравнению с нормальными тасками. Только и всего Ещё раз. Виртуальные потоки — совсем про другое.
Вкратце, как я понимаю, основная проблема зелёных потоков — взаимодействие с неуправляемым кодом.
Java пытается выехать на том, что весь код — управляемый, и все блокирующие IO операции заботливо подменены под капотом на вызовы неблокирующих с последующим yield.
Если мы имеем несчастье вызвать какую-то IO библиотеку, которая написана до JDK 21, то виртуальный поток вполне успешно встанет в ожидание, сожрав поток ОС.
Но это — чисто performance issue, т.е. старый код продолжит работать так же, как он работал в старом JDK. Апгрейд на версию библиотеки, адаптированную к JDK 21, даст автоматическое улучшение масштабируемости приложения без переписывания кода.
Хуже — ситуация, когда мы вызываем какой-то неуправляемый код, который напрямую лезет в TLS средствами операционки. Приняты ли в JDK 21 какие-то меры борьбы с таким поведением?
Если нет — то приложение просто взорвётся при переходе на виртуальные потоки.
В остальном — конечно, было бы прикольно иметь возможность прозрачного использования кооперативной многозадачности без утомительного переписывания прямолинейного кода на код с async/await.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Serginio1, Вы писали:
P>>IO в данном случае уже поддерживается рантаймом, перешедуливание будет работать само. А вот всё остальное нужно разумеется вставлять связку самостоятельно, ровно так же, как вы это делаете через ContinueWith итд.
S> Ну и какой смысл в ограниченном IO?
Ограниченный io это ваша выдумка.
>Если все равно приходится использовать таски с CancellationToken или граф тасков. Виртуальные потоки это для старого кода.
У вас очень бурная фантазия
S>В новом коде как правило все уже асинхронно и нет смысла устраивать зоопарк!
Здесь разговор про джаву — супердешовые потоки на кооперативной многозадачности.
Те это тот самый движок для асинхронности, который не требует изменения в яп.
Здравствуйте, Sinclair, Вы писали:
S> Если мы имеем несчастье вызвать какую-то IO библиотеку, которая написана до JDK 21, то виртуальный поток вполне успешно встанет в ожидание, сожрав поток ОС.
Если эта IO-библиотека использует у себя внутри JNI, тоже написанный до 21, то да, тут оно и выжрет поток.
А если она использует тот же JDK-шний io, то всё ок.
S> Но это — чисто performance issue, т.е. старый код продолжит работать так же, как он работал в старом JDK. Апгрейд на версию библиотеки, адаптированную к JDK 21, даст автоматическое улучшение масштабируемости приложения без переписывания кода.
Да. Ещё расчёт на то, что в java принято писать pure-решения. В отличие от того же c#, где на каждый чих DllImport.
S> Хуже — ситуация, когда мы вызываем какой-то неуправляемый код, который напрямую лезет в TLS средствами операционки. Приняты ли в JDK 21 какие-то меры борьбы с таким поведением? S> Если нет — то приложение просто взорвётся при переходе на виртуальные потоки.
Да. Возможная грабля, похоже. В смысле вряд ли оно это сможет обнаружить как-то. Но ведь реальные треды никуда не уходят. Если есть такой код, который плотно взаимодействует с нативом и делает всякие странные вещи, то его можно всё ещё пускать на реальных тредах.
Здравствуйте, ·, Вы писали: ·>А если она использует тот же JDK-шний io, то всё ок.
Ну я не особый знаток джавного ландшафта; но помимо стандартного IO в виде файлов/сокетов могут быть всякие сторонние решения.
То есть понятно, что если у нас есть какой-нибудь JDBC-шный драйвер, который внутре лезет на сервер через стандартный сокетный API, то всё зазеленеет само.
А если там какой-то high performance код, который работает с сетевой карточкой в чистой юзермоде, то чудес не случится. ·>Да. Ещё расчёт на то, что в java принято писать pure-решения. В отличие от того же c#, где на каждый чих DllImport.
Я так и подумал. Получается, тут преимущество java является обратной стороной её недостатка — трудности интеграции с нативным hi-perf кодом помогают оптимизировать low-perf код.
S>> Если нет — то приложение просто взорвётся при переходе на виртуальные потоки. ·>Да. Возможная грабля, похоже. В смысле вряд ли оно это сможет обнаружить как-то. Но ведь реальные треды никуда не уходят. Если есть такой код, который плотно взаимодействует с нативом и делает всякие странные вещи, то его можно всё ещё пускать на реальных тредах.
Тут главное — понять, можно ли пускать. В джаве популярны стеки глубиной в сотни вызовов. Вполне невинный гражданский код, который вызывает что-то из pure-java пакета, может через сотню-другую вызовов упереться в какой-то JNI, да ещё и зависимым от конфигурации образом. То есть в домашних тестах всё будет летать огнём, а в проде какая-нибудь экзотическая зависимость неожиданно стрельнет .
Я не спец в low-level; поэтому не знаю — есть ли способ определить, лазил ли сделанный нами вызов натива в TLS, чтобы сделать хотя бы fail fast с внятной диагностикой (вместо чтения мусора).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>·>А если она использует тот же JDK-шний io, то всё ок. S>Ну я не особый знаток джавного ландшафта; но помимо стандартного IO в виде файлов/сокетов могут быть всякие сторонние решения. S>То есть понятно, что если у нас есть какой-нибудь JDBC-шный драйвер, который внутре лезет на сервер через стандартный сокетный API, то всё зазеленеет само. S>А если там какой-то high performance код, который работает с сетевой карточкой в чистой юзермоде, то чудес не случится.
Ну как бы да. С другой стороны, вылизанного hiperf кода не так уж и много. Тем более там скорее всего нутро будет завязано на определённые режимы операционки и железа, ну чтоб cpu affinity, irq, numa. Но это же только транспорт в приложении, один железный поток, как правило логически относительно примитивный, а потом он может выдавать это толпе виртуальных, которые запутанную бизнес-логику делают.
S>·>Да. Ещё расчёт на то, что в java принято писать pure-решения. В отличие от того же c#, где на каждый чих DllImport. S>Я так и подумал. Получается, тут преимущество java является обратной стороной её недостатка — трудности интеграции с нативным hi-perf кодом помогают оптимизировать low-perf код.
Java упор на managed делает. А шарп пытается на двух стульях усидеть.
Впрочем, java тоже аккуратно добавляет безопасный FFM.
S>·>Да. Возможная грабля, похоже. В смысле вряд ли оно это сможет обнаружить как-то. Но ведь реальные треды никуда не уходят. Если есть такой код, который плотно взаимодействует с нативом и делает всякие странные вещи, то его можно всё ещё пускать на реальных тредах. S>Тут главное — понять, можно ли пускать. В джаве популярны стеки глубиной в сотни вызовов. Вполне невинный гражданский код, который вызывает что-то из pure-java пакета, может через сотню-другую вызовов упереться в какой-то JNI, да ещё и зависимым от конфигурации образом. То есть в домашних тестах всё будет летать огнём, а в проде какая-нибудь экзотическая зависимость неожиданно стрельнет .
Вроде добавляют диагностику какую-то для отслеживания pinned-потоков, что будет индикацией jni-вызовов.
S>Я не спец в low-level; поэтому не знаю — есть ли способ определить, лазил ли сделанный нами вызов натива в TLS, чтобы сделать хотя бы fail fast с внятной диагностикой (вместо чтения мусора).
В смысле внутри нативного колла? Не знаю тоже, думаю от операционки зависит.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Это не моя выдумка. Что автор сказал, то и повторил. Все претензии к автору топика. >>Если все равно приходится использовать таски с CancellationToken или граф тасков. Виртуальные потоки это для старого кода.
P>У вас очень бурная фантазия
Это реальная жизнь! S>>В новом коде как правило все уже асинхронно и нет смысла устраивать зоопарк!
P>Здесь разговор про джаву — супердешовые потоки на кооперативной многозадачности. P>Те это тот самый движок для асинхронности, который не требует изменения в яп.
Я это прекрасно понимаю. Но я обратил внимание на недостатки.
Да для старого кода это киллер фича. Для тасков я так понимаю нет acync/await
и солнце б утром не вставало, когда бы не было меня
S> Это не моя выдумка. Что автор сказал, то и повторил. Все претензии к автору топика.
Я такого не говорил. Так что претензии лишь к твоему умению читать.
Или цитату в студию.
Здравствуйте, ·, Вы писали:
А где я говорил про ограниченный IO. Я говорил про IO ! Ссылки в студию!
Ограниченный IO имеллось виду, что поддерживается только IO/
На мой вопрос про соккееты ты ответил про полный IO но не добави какие eще поддерживает методы.
Я сказал, что по сравнению с TaskCompletionSource это сильно ограниченное решение!
Только и всего.
Ну в итоге вот полный список http://rsdn.org/forum/philosophy/8525873.1
Здравствуйте, Serginio1, Вы писали:
S> ·>И где там "ограниченный IO"? Ты буковки вставь, и контекст таки прочитай моих фраз. S> А где я говорил про ограниченный IO. Я говорил про IO ! Ссылки в студию! Здесь:
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>> ·>И где там "ограниченный IO"? Ты буковки вставь, и контекст таки прочитай моих фраз. S>> А где я говорил про ограниченный IO. Я говорил про IO ! Ссылки в студию! ·>Здесь:
Ещё раз. Виртуальные потоки — совсем про другое.
.
