Reindex.. please wait

Возвращаясь к сегодняшней теме. Посмотрите реализацию / интерфейс / тесты с асио https://github.com/inkooboo/thread-pool-cpp Кто что думает?

Использует MPMCBoundedQueue, как я понял

@JegernOUTT https://github.com/bloomen/cxxpool/blob/master/src/cxxpool.h

Reindex.. please wait

Вместо ГОрутин

Ну вот сходу гуглится тредпул в хашнике

Вместо ГОрутин

Reindex.. please wait

Там с пулом

Reindex.. please wait

Reindex.. please wait

Трудоемкость алгоритма где for в for и все это в while, конеш аховая, но бывает надо наверное, да

Мне нужно обработатьребра полного графа так что пофигу

И это в цикле делать

Reindex.. please wait

Смотря что за корутины, и что за компилятор.

За нативные надо, за компиляторные стейтлесс не надо.

Но в обоих случаях быстрее чем треды, разумеется.

Reindex.. please wait

Ваще не понял в чём прикол библиотеки.

Взяли обычную блокирующую очередь, добавили в пуш trylock, прикрутили тредпул и написали всяких штук, которые просто в стандарте не сделали типа then

Разве так любая контора которая на плюсах пишет не делает сама?

Разве так любая контора которая на плюсах пишет не делает сама?

Согласен. Такой тредпул на коленке в черновом варианте за час делается

Хотя нет, я перепутал с другой библиотекой)

Там повыше есть одна примитивная

https://github.com/bloomen/cxxpool/blob/master/src/cxxpool.h

Не, это реально на коленке, я про адобовскую.

Взяли обычную блокирующую очередь, добавили в пуш trylock, прикрутили тредпул и написали всяких штук, которые просто в стандарте не сделали типа then

Reindex.. please wait

функциональности*

Да нет, ничего не ждать, просто к ней было такое вступление текстовое, как будто это brand new решение.

функциональности*

Reindex.. please wait

А на самом деле это просто то, как должно было быть изначально сделано в плюсах.

Это хорошее решение. Сам так делал.

Хотя в итоге всё равно сделал корутины.

Ажно в 2014-15

поделись? просто посмотреть красоту реализации корутин

No way :D

Строжайший NDA

Строжайший NDA

ты не с яндекса случайно? ?

Это стало core-либой в одной компании, которая занимается HFT

Не.

Хедж-фонд.

Который 10% дневного оборота на фондовых рынках в РФ проворачивает.

Ты на boost context с нуля корутины делал? или готовые брал?

Лол.

Ни то, ни другое.

Я их вообще с нуля делал.

Буст контекст в 2014 еще работал очень хуёво. Только время на него потратил.

Не знаю как сейчас.

Мне надо было сдлеать кросплатформенные кортуины.

Под виндой это были файберы. На линуксе это был ucontext_t

И соотв. вызовы.

На маке ни того, ни другого, пришлось написать на ассемблер гет и сет контекстов.

понятно. и много времени на это всё ушло?

20 нс на контекст свитч зато.

Где-то 4 месяца from scratch

Я писал для мака и линукса и второй разработчик для винды.

В итоге был библиотека корутин, совмещенная с асинхронным ио

IOCP в винде, epoll в линуксе и kqueue в Mac

Довольно забавно видеть было выступление Гора Нишанова в 2016 году с его TcpConnection классом на корутинах и await-ах, когда ты сам это уже писал два года назад.

Ну вот, теперь ты меня смутил. Тоже хочу корутины. Только готовые) пойду смотреть boost

Но это стейтфул корутины. Они конечно всё равно быстрые, 20 нс, как я уже сказал, но это не зиро-оверхед.

Есть настоящий зиро-оверхед, но его только компилятор может сделать.

Это следующий шаг и гораздо более непростой, но я вот как раз этим занят :D

Разрабатываю дизайн языка для одного проекта стороннего, где будут корутины из коробки стейтлесс в компиляторе.

20 нс на контекст свитч зато.

Power8 пробовали?

Там ещё быстрей.

Чучуть, но шустрей Intel.

Кто-нибудь с epoll и сокетами работал тут? Это нормально будет, если я создам cпомощью epoll_create(1) один epoll дескриптор и из кучи потоков подпишусь на него через epoll_wait?

На стэке пишут что ок, но как-то это ненадёжно выглядит

ERROR: S client not available

http://stackoverflow.com/questions/12481245/epoll-wait-on-several-threads-faster

Это ок.

Хотя вопрос в чём?

Да, epoll_wait тредсейфный.

Хотя вопрос в чём?

меня вот это просто насторожило "and be careful about synchronisation"

А, ну смотри, ты разницу межде edge-triggered и level-triggered понимаешь?

Эдж срабатывает по фронту сигнала, левел срабатывает и держится пока сигнал есть.

В данном случае сигнал — это готовность сокета.

еполл это очередь.

Если у тебя ET, то ты вытащишь из еполла гарантированно один раз.

сокет

А вот если LT

То может случить и так, что два треда вытащат один и тот же сокет.

Естественно предполагается, что у тебя O_NONBLOCK сокеты.

?спасибо. А нельзя сделать так что бы дескрипторы которые попали в один тред оставались только там? Т.е. я подписался через epoll на сокет, он мне насоздавал соединений. Я прочитал из сокетов и решил в них записать данные. Но готовность на запись может прийти в другой поток ведь так?

Да, это так.

А что, ты хочешь чтобы у тебя тред простаивал, пока не будет доступна запись?

В чем выигрыш от еполла тогда?

Он не для такой архитектуры :)

У меня просто такой алгоритм: 1. клиент отправляет данные 2. Подсчитывается хэш сумма и отправляется в ответе клиенту. Думаю через одно соединение это сделать как раз ок

Понятно, ну ты всегда можешь удалить из еполла свой сокет.

А что, ты хочешь чтобы у тебя тред простаивал, пока не будет доступна запись?

Ну не совсем простаивал, просто тред бы обрабатывал другие события, а при появлении события на запись залазил бы в локальный объект(хэш мап), вытаскивал оттуда данные отправлял их и закрывал соединение

Бррр.

Ты хочешь от треда слишком много.

Тебе пришло соединение, тред прочел данные и начал считать хеш.

Он в этот момент занят, так?

Ага, получается что так. Я херню сказал)

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

Еще лучше их сделать корутинами :D

Но да.

Лучше пусть твоя долгая операция подсчета хеша не смешивается с чтением и записью данных.

Эх. Я просто подумал что раз epoll thread-safe, то я всю эту штуку без блокировок как-то смогу сделать :D