а зачем мне ее знать?

поэтому и написал, что корутины не будут быстрее потоков

корутины будут на i/o задачах зачастую быстрее потоков

корутины будут на i/o задачах зачастую быстрее потоков

обоснуй

а зачем мне ее знать?

потому что если ты не понимаешь разницу между ними - ты не понимаешь предмет от слова "совсем"

обоснуй

читай выше, уже разжевали

я сделаю 1 поток ассептор и n воркеров, с чего тут быть быстрее корутинам?

если ты решил придраться, что без создания main thread не запустишь epoll и не создашь корутин - то это клиника

я сделаю 1 поток ассептор и n воркеров, с чего тут быть быстрее корутинам?

с того, что это УЖЕ вариант корутин

да с херали?

это просто потоки)

это просто потоки)

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

можешь

а можешь и в одном потоке это сделать

и что будет быстрее - большой вопрос

тогда твое утверждение о том, что они быстрее сосет вдвойне

тогда твое утверждение о том, что они быстрее сосет вдвойне

ты дурак?

ну ты мне скажи, за счет чего они будут быстрее?

раз ты не дурак

когда у тебя много тредов - тебе как минимум надо тратить ресурсы на общение с ними

Я джва года ждал годный срачик!

шедулер системный будет поверх этого всего еще бегать и контекст переключать

поэтому и написал, что корутины не будут быстрее потоков

Ты то говоришь про иногда, а теперь утверждашеь что "не будут". Будут в определенных задачах где нагрузка на io не так высока. Потоки будут кушать больше процессорного времени, поэтому и у них получше с общим io, но тк он ложится на шедулер - мы теряем скорость инициализации и имеем оверхед на синхронизацию, чего нет с сопрограммами + потоки надо чаще оборачивать механизмами синхронизации что опять чревато дрочкой смены контекста(в случае с мютексами). Здесь атомики еще спасают как-то

1 кто тебе сказал, что я буду делать синхронизацию?)

ченел привязан к потоку, че мне там синкать то

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

ченел привязан к потоку, че мне там синкать то

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

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

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

про пулы не слышал?

про пулы не слышал?

в пулах потоки как-то по-другому работают штоле? не пиши ерунду

они созданы уже)

потоки есть потоки, хоть пулом их создавай, хоть pthread_create

1 кто тебе сказал, что я буду делать синхронизацию?)

Ну например у тебя есть мастер и воркеры, воркеры будут иметь механизмы синхронизации друг с другом? - Будут. Те даже если оно будут иметьп прединициализацию будут происходить задержки. Но в контексте веб серверов это целесообразно тк там io нужен максимальный

они созданы уже)

окей, и? тебе в них данные передавать надо все равно

Ну например у тебя есть мастер и воркеры, воркеры будут иметь механизмы синхронизации друг с другом? - Будут. Те даже если оно будут иметьп прединициализацию будут происходить задержки. Но в контексте веб серверов это целесообразно тк там io нужен максимальный

зачем?

Ну например у тебя есть мастер и воркеры, воркеры будут иметь механизмы синхронизации друг с другом? - Будут. Те даже если оно будут иметьп прединициализацию будут происходить задержки. Но в контексте веб серверов это целесообразно тк там io нужен максимальный

я ж сказал решение, канал привязывается к потоку, все - конкуренции нет

Я джва года ждал годный срачик!

Ерунда. Это ещё гоферы и остальной мир не срались. Там адок творится, да.

зачем?

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

как минимум

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

в одном потоке

я ж сказал решение, канал привязывается к потоку, все - конкуренции нет

Ну, понимаешь ли, в веб серверах все не так просто. Ибо есть механизмы релоадинга конфигов(аля нжи). Везде есть синхронизация

в одном потоке

у тебя их уже два. Воркер и тот, который сокет слушает

Ну, понимаешь ли, в веб серверах все не так просто. Ибо есть механизмы релоадинга конфигов(аля нжи). Везде есть синхронизация

это другой уже вопрос

я вам в пример привел netty

это другой уже вопрос

на практике синхронизация нужна в 90% случаев

я вам в пример привел netty

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

на практике синхронизация нужна в 90% случаев

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

вот тебе вопрос на засыпку

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

ну тебе никто не мешает там логику написать в хендлере)

что быстрее: 1) передать контекст управления внутри одного треда другой функции 2) отправить сообщение в тред и дождаться ответа из него

можешь взять помощь зала, если не знаешь

думаю что первое)

угадал?)

бинго!

именно по этому принципу и работают однотредовые приложения на корутинах

так что твои построения с тредами выше невалидны

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

вся остальная работа идет в одном треде и это получается твои первый вариант

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

как, интересно, он им это говорит, если ты ничего не передаешь?

вся остальная работа идет в одном треде и это получается твои первый вариант

шта? у тебя уже есть треды-воркеры, откуда в одном треде?

я тебе про netty ты мне про один тред

таких систем то нет уже)

я тебе про netty ты мне про один тред

да срал я на твой netty

это лишь один из примеров, причем не самый удачный

потому что там гибридный режим

который, разумеется, быстрее однопоточного сервера

ERROR: S client not available

я че хотел сказать то изначально

что все зависит от реализации

и в тредах, ты можешь наворотить куда более крутые штуки

и врядли они будут медленнее корутин

в тредах куда проще наворотить кучу говна

и врядли они будут медленнее корутин

разумеется, на i/o операциях, будут

с чего вдруг?)

мы же уже выяснили что нет

мы же уже выяснили что нет

мы уже выяснили, что да

нет

даю еще одну подсказку-вопрос

давай

только не про апач и нжинкс плиз

только не про апач и нжинкс плиз

не, про них ты уже слился

ща

что быстрее: 1) навесить луп на прием событий от системы, и запускать код только когда эти события приходят, не пересылая никуда ничего 2) при приходе данных в хэндлер передавать управление этим хэндлером обработчику в потоке, который возвращает управление, только обработав данные

вы кто-нибудь на С писали?

бонус: первое - так работает торнадо в общем случае, второе - так работает апач и прочие тредовые сервера

а то уже подустать можно от вашей переписки

вы кто-нибудь на С писали?

все когда-то это делали)

вы кто-нибудь на С писали?

+

что быстрее: 1) навесить луп на прием событий от системы, и запускать код только когда эти события приходят, не пересылая никуда ничего 2) при приходе данных в хэндлер передавать управление этим хэндлером обработчику в потоке, который возвращает управление, только обработав данные

дык первое не мешает делать на потоках ?

i7 7700hq оказался оч так себе

дык первое не мешает делать на потоках ?

"не пересылая никуда ничего", так что мешает

разумеется, зачем мне треды на epoll?

https://www.nginx.com/blog/thread-pools-boost-performance-9x/ вот для этого

https://www.nginx.com/blog/thread-pools-boost-performance-9x/ вот для этого

опять же, гибридный подход, да, я про это и не спорю

все, я пошел

Колюня - ты не прав

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

давайт процы обсудим

нету, хоть 10