·>А зачем он везде в общем случае? Специальная конструкция как в CancellationToken не требуется.

M>>Если реализовать cancellation (как я понимаю, применительно к IO в Java это делается через AsynchronousChannel), то будут Future (вместо Task). И в итоге можно получить тот же function coloring
·>Если у тебя есть какой-то сокет и ты хочешь прервать код, который на нём ждёт слишком долго, то поставь таймаут. Или если какое-то внешнее взаимодейсвтие, что сокет больше не нужен — закрой сокет. И т.п.
·>Т.е. какой-то универсальный cancellation не нужен.

Таймаут выбирается исходя из условий задачи (удаленность сервера в сети и т.п.).
Закрытие сокета не всегда годится. Что если мне нужно прервать конкретную IO операцио, а потом продолжить работу с сокетом.
Это все плохие решения, к которым приходится прибегать, если API не оставляет других вариантов.

non-blocking I/O можно прервать через Thread.interrupt, но у этого флага весьма специфическое поведение: clearance.
Как учесть это в стороннем коде, мне не ясно.

	См. https://stackoverflow.com/a/37207163
	Here's a SUPER FUN EXAMPLE: ch.qos.logback.core.AsyncAppenderBase prior to version 1.1.4 catches and swallows InterruptedException without resetting the flag on the thread. So, if you use anything which routes to this logger (like slf4j), it will silently eat your thread interrupt status. 'Cos, I mean, who doesn't check thread interrupt status before and after every possible log operation?

Из чего я делаю вывод, что cancellation для IO/CPU-bound задач нужно реализовать иным способ — добавлять перегруженные методы c аналогом CancellationToken, либо использовать Future.

При работе с IO/CPU-bound кодом надежный cancellation для меня даже более критичен, чем потенциальный расход ресурсов на тяжеловесные потоки.
Поэтому я не согласен с аргументом о том, что virtual threads позволят избежать необходимости перегрузки (или реализации через Future) существущих синхронных методов типа readAllBytes.

·>А зачем он везде в общем случае? Специальная конструкция как в CancellationToken не требуется.

M>>Если реализовать cancellation (как я понимаю, применительно к IO в Java это делается через AsynchronousChannel), то будут Future (вместо Task). И в итоге можно получить тот же function coloring
·>Если у тебя есть какой-то сокет и ты хочешь прервать код, который на нём ждёт слишком долго, то поставь таймаут. Или если какое-то внешнее взаимодейсвтие, что сокет больше не нужен — закрой сокет. И т.п.
·>Т.е. какой-то универсальный cancellation не нужен.

Таймаут выбирается исходя из условий задачи (удаленность сервера в сети и т.п.).
Закрытие сокета не всегда годится. Что если мне нужно прервать конкретную IO операцио, а потом продолжить работу с сокетом.
Это все плохие решения, к которым приходится прибегать, если API не оставляет других вариантов.

non-blocking I/O можно прервать через Thread.interrupt, но у этого флага весьма специфическое поведение: clearance.
Как учесть это в стороннем коде, мне не ясно.

	См. https://stackoverflow.com/a/37207163
	Here's a SUPER FUN EXAMPLE: ch.qos.logback.core.AsyncAppenderBase prior to version 1.1.4 catches and swallows InterruptedException without resetting the flag on the thread. So, if you use anything which routes to this logger (like slf4j), it will silently eat your thread interrupt status. 'Cos, I mean, who doesn't check thread interrupt status before and after every possible log operation?

Из чего я делаю вывод, что cancellation для IO/CPU-bound задач нужно реализовать иным способ — добавлять перегруженные методы c аналогом CancellationToken, либо использовать Future.

При работе с IO/CPU-bound кодом надежный cancellation для меня даже более критичен, чем потенциальный расход ресурсов на тяжеловесные потоки.
Поэтому я не согласен с аргументом о том, что virtual threads позволят избежать необходимости перегрузки (или реализации через Future) существущих синхронных методов типа readAllBytes.

P.S. nickname у сообщения почему-то поменялся на Аноним Правильный nick — m2user