« Rev
@rustlang_ru   135
Fwd »


Anonymous
что с ним надо сделать
Маjко
Я этого не говорил, там есть пул.
И диспетчеризация задач на пул потоков — это не задача планировщика, ты хочешь сказать?
Мерль
В го кооперативная многозадачность с шедулером поверх пула потоков И да, у него мало время отклика в случае сетевого io, т.к там нет на него блокировок
Он там довольно хитрый конечно, у горутин резиновый стек и их перекидывают из потока в поток, если тот заблокирован, но всё же
Маjко
что с ним надо сделать
ЕМНИП, если замыкание возвращает Result, то оно приводится к фьюче
Anonymous
о
Anonymous
спасибо
Маjко
Да ты заебал, я тебе подобного нигде не писал)
Нет, писал. > Поток селектор отдаёт инфу потокам воркерам о том, что в ченеле есть записи. Отдаём в очередь и радуемся. Какие там планировщики нужны) А теперь ты соглашаешься что диспетчеризация задач на пул потоков — задача планировщика
Маjко
Хммм
Еще есть функции в futures::future для создания фьюч-пустышек, можно с ними скомбинироваться
Маjко
Это в любом случае задача планировщике ос. Речь шла о том, что не нужно писать свои планировщик
Да шой то ты говоришь. Тебе ОС сама задачи создаст из событый epoll, сама создаст потоки, сама поднимет очередь синхронизации, сама туда отправит задачи?
Anonymous
Сколько в твоём примере бизнес задач на поток?
Странный вопрос, сколько угодно
Мерль
Странный вопрос, сколько угодно
Что будет, если поток заблочится?
Маjко
Это в любом случае задача планировщике ос. Речь шла о том, что не нужно писать свои планировщик
И да, когда у тебя не статику отдавать из памяти, а работать с диском асинхронно, то твой планировщик сиьно пухнет, блокировать то потоки нельзя
Маjко
И тут мы возвращаемся к вопросу нафига писать свой костыль над epoll
Anonymous
Да шой то ты говоришь. Тебе ОС сама задачи создаст из событый epoll, сама создаст потоки, сама поднимет очередь синхронизации, сама туда отправит задачи?
Ещё раз, есть поток селектор. Который собирает из епола ивенты. Дальше он даёт инфу воркерам(это пул). Все! Это не планировщик
Мерль
Плохо будет
А в Go не будет
Мерль
Такие дела
Anonymous
Потому что там с потоками никто не работает
Маjко
Ещё раз, есть поток селектор. Который собирает из епола ивенты. Дальше он даёт инфу воркерам(это пул). Все! Это не планировщик
Так что твои воркеры будут делать, если им надо самим работать асинхронно с чем бы то ни было сторонним? Это вырастет в огромную стейт машину, тогда как стекфулл корутины в го эту проблему решают элегантно
Мерль
Потому что там с потоками никто не работает
Напрямую - нет. Очень удобно, нигде не натирает и ваще
Маjко
Потому что там с потоками никто не работает
Это и не нужно. Когда для того чтобы смасштабивать свое приложение на количество CPU тебе приходится устраивать самостоятельно пляски с бубном, писать стейт машины и херачить синхронизацию — это не нормально
Anonymous
Так что твои воркеры будут делать, если им надо самим работать асинхронно с чем бы то ни было сторонним? Это вырастет в огромную стейт машину, тогда как стекфулл корутины в го эту проблему решают элегантно
Что значит асинхронно в твоём понимании? Ну сунул в другой ченел данные , там дальше селектор снова чтот поймает и вперёд. Какая стеит машина? Простой пайп
Маjко
Что значит асинхронно в твоём понимании? Ну сунул в другой ченел данные , там дальше селектор снова чтот поймает и вперёд. Какая стеит машина? Простой пайп
Да что ты. А состояние задачи у тебя куда денется? Вот твой поток принял соединение, асинхронно обратился к Redis, epoll поймал ивент, снова приходит задача в этот же поток, он обрабатывает соединение с Redis... и... черт, а зачем ему это было нужно?
Маjко
Да даже без редиса, просто 10 клиентов на один поток и более сложная задача чем просто чтение данных, отправленных клиентом по TCP
Маjко
Уже нужны состояния
Маjко
Возьми да прочитай в буфет да и работай как хочешь
Ты понимаешь, что это блокирующая операция, я надеюсь?
Anonymous
Да и вообще причём тут это
Маjко
Ты придуриваешься? Чтение из сокета в буфер
Anonymous
Ну и пусть ,в чем проблема то)
Маjко
При том что ты затираешь за отзывчивость и блокирующие операции в тредпуле для тебя — норм
Anonymous
С чего вдруг то
Anonymous
У тебя не один воркер ж
Маjко
Ахахах
Маjко
А сколько?
Маjко
10 тысяч?
Маjко
100 тысяч?
Маjко
По количеству клиентов?
Маjко
Ахахахах
Anonymous
Нет
Маjко
Нахуй тогда вообще нужен epoll и тредпул
Anonymous
Пиздец ты тугой
Anonymous
Я хз как тебе объяснить
Маjко
Ты несешь хуйню
Маjко
Какие нахуй блокирующие операции в отзывчивой системе
Маjко
О чем ты
Маjко
Ты блокируешь все твои 4 потока
Маjко
И всё
Маjко
Пока 4 клиента не дошлют данные — ты не можешь принимать клиентов
Маjко
Ты точно не хочешь танненбаума почитать?
Маjко
Да ладно Танненбаума
Маjко
Хоть Stack Overflow
Маjко
Ща я тож открою, зацитирую прям
Anonymous
Кто тебе сказал, что в буду в буфере читать до eof
Anonymous
Ну вот кто
Маjко
Да не важно до скольки ты там читаешь, если ты блокируешь поток
Маjко
Когда у тебя операция асинхронна, ты переключаешься на другую пока данные не пришли в буфер
Маjко
И не ждешь данные
Маjко
Поток не заблокирован
Маjко
Никогда
Anonymous
Вот почитай пеипер
Маjко
Тебе non-blocking io ни о чем не говорит?
Anonymous
Так все джава сервера работают
Маjко
> non-blocking io
Маjко
Ты понимаешь, что это блокирующая операция, я надеюсь?
Маjко
Ты придуриваешься? Чтение из сокета в буфер
Маjко
Ну и пусть ,в чем проблема то)
Anonymous
Иди почитай
Маjко
У тебя НИКОГДА не блокируются io операции
Anonymous
Прекрати петушиться
Маjко
Да сам почитай, ты базовых вещей не понимаешь. У тебя в отзывчивых системах блокирующие IO операции — это норма
« Rev
@rustlang_ru   135
Fwd »