Новое сообщение в форум Философия программирования

Форум	Философия программирования
Тема	Как правильно задавать вопросы

Здравствуйте, ·, Вы писали:

·>Здравствуйте, m2user, Вы писали:

А>> ·>Т.е. какой-то универсальный cancellation не нужен.
А>> Таймаут выбирается исходя из условий задачи (удаленность сервера в сети и т.п.).
А>> Закрытие сокета не всегда годится. Что если мне нужно прервать конкретную IO операцио, а потом продолжить работу с сокетом.
·>Это уже как-то сложно и наворочено получается. Скажем, работает у тебя операция чтения в массив размером в 100 мегабайт. Половину вычиталось из сокета, и тут пришел сигнал на отмену. Что с этим делать? Вкачать выкачанное обратно в интернет?
·>Так что разумный вариант - закрывать сокет, прерывать чтение исключением. Что interrupt в сабже и делает, если я не ошибаюсь.

А>> Это все плохие решения, к которым приходится прибегать, если API не оставляет других вариантов.
·>Если не заниматься усложнизмом, то всё ок.

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

А>> Как учесть это в стороннем коде, мне не ясно. :xz:
·>Это как бы [s]баги[/s]"особенности" конкретного кода. Никто не запретит "особым" образом обрабатывать CancellationToken (если вообще ты как-то умудришься его протащить внутрь сторонней либы логгирования).

А>> Из чего я делаю вывод, что cancellation для IO/CPU-bound задач нужно реализовать иным способ - добавлять перегруженные методы c аналогом CancellationToken, либо использовать Future.
А>> При работе с IO/CPU-bound кодом надежный cancellation для меня даже более критичен, чем потенциальный расход ресурсов на тяжеловесные потоки.
·>Честно говоря, не очень понимаю юзкейсы этого.  Зачем надо всё делать отменяемым?
·>Насколько часто такое надо делать? Потому что если это какие-то corner cases, там это можно реализовать вручную, а не протаскивать везде и всюду.

А>> Поэтому я не согласен с аргументом о том, что virtual threads позволят избежать необходимости перегрузки (или реализации через Future) существущих синхронных методов типа readAllBytes.
·>Не знаю насколько это необходимо, но это ортогонально virtual threads. Добавят, так добавят.

Теги:

Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например: "Visual Studio" .NET

Имя, пароль: Загрузить Нравится наш сайт? Помогите его развитию!
Отключить смайлики Получать ответы по e-mail