Кто нить пишет на qt?
да
Alexander "SonnySlave"
Анаит
Alexander "SonnySlave"
обращайся
Andrei
https://isocpp.org/files/papers/N4402.pdf на пятой странице официальная позиция :)
Прочитал, не понял откуда этот мегабайт взялся. Я уже года два-три живу со стейтфул корутинами и выглядит это так, что ты отдаёшь пару килобайт под стек, и только если надо — увеличиваешь потом, так что аргумент про память мягко говоря не аргумент.
Andrei
Что же касается фрагментированных стеков, так ведь большинство библиотек как раз таки потребуют полного переписывания, потому что async await «заражает» весь вызывающий код.
Andrei
А стейтфул корутины вполне изолированно могут жить. К примеру, я прикручивал ssl поверх своего асинхронного корутинового io. Прям используя read/write из асинхронного TcpConnection.
Andrei
Не меняя в коде SSL библиотеки ровным счетом ничего.
Constantine
Я правильно понимаю, что stackless coroutines это сахарный способ записи future-цепочки вычислений?
Andrei
Я понимаю, что 40 инструкций (на самом деле и того меньше) на переключение контекста вместо 10 — это кошмар оверхед, но всё-таки по коду гораздо красивее. Короче мой поинт в том, что могли бы и то и другое в стандарт добавить.
Andrei
Я правильно понимаю, что stackless coroutines это сахарный способ записи future-цепочки вычислений?
Сорт оф. Это то, что компилятор на этапе компиляции может сшить обратно в одну здоровенную функцию.
Andrei
В тех местах где это порезано асинхронными вызовами.
Constantine
Сорт оф. Это то, что компилятор на этапе компиляции может сшить обратно в одну здоровенную функцию.
Хм... локальные переменные функции-то хоть захватываются?)
🐙 Antony
Я понимаю, что 40 инструкций (на самом деле и того меньше) на переключение контекста вместо 10 — это кошмар оверхед, но всё-таки по коду гораздо красивее. Короче мой поинт в том, что могли бы и то и другое в стандарт добавить.
stackful никто не запрещает по прежнему использовать. А вот stackless без поддержки компилятора реализовать не возможно, поэтому тащат в компилятор
Andrei
stackful никто не запрещает по прежнему использовать. А вот stackless без поддержки компилятора реализовать не возможно, поэтому тащат в компилятор
Это правда. Просто стекфул тоже было бы неплохо стандартизировать.
Constantine
Сорт оф. Это то, что компилятор на этапе компиляции может сшить обратно в одну здоровенную функцию.
А это описание точное для времени жизни всех объектов?
Andrei
Хм... локальные переменные функции-то хоть захватываются?)
По коду это выглядит как обычные функции, вообще ничего сверхъестественного. Программисту только надо в правильных местах расставлять ключевые слова async await.
Andrei
За временем жизни следить надо руками, это правда.
Constantine
Я имею в виду
Andrei
Но это верно хоть для стейтфул корутин, хоть для стеклесс корутин, хоть для тредов.
Constantine
void f {
int local = 0;
int another = co_await something;
local доступна?
}
Andrei
Да. Конечно.
Andrei
Она как лежала себе на стеке так и лежит спокойно.
Andrei
Интересности могут возникнуть вот как у Антона в примере выше.
Andrei
Когда аргумент пришел по ссылке и к моменту вычисления результата уже грохнулся.
Constantine
А можно примерно объснить как работают stackless coroutines?
Constantine
в действительности цель co_await представляет собой захваченный по ссылке контекст функции?
Constantine
в состоянии "продолжать здесь"?
Andrei
Там есть несколько keypoints: resumable contexts и прочие страшные слова, смысл примерно в том, что программист пишет код так, как будто бы у него полноценные отдельные контексты для функций, которые могу прерываться и уступать процессор другим, а компилятор анализируя эту портянку строит по ней конечный автомат и разворачивает в страшные свич-кейсы.
Andrei
Думаю можно посмотреть любой видос Нишанова на эту тему.
Andrei
в состоянии "продолжать здесь"?
Сорт оф. В стекфулл корутинах там актуально в структурку складывается eip, esp, прочие ребята, кладётся в лист, вытаскивается элемент из головы и из него восстанавливаются новые eip, esp, регистры.
Andrei
В случае стеклесс корутин — это абстракция и реально этого не происходит, а просто умный компилятор сам знает куда надо передать управление.
Andrei
Сам следит что как ему разложить в регистры, как спрятать один стек от другого.
Constantine
А чем плоха модель с заданием вычислителя в виде функции без контекста с последующим "я тут пивасик пойду, посчитай мне"? :)
🐙 Antony
А чем плоха модель с заданием вычислителя в виде функции без контекста с последующим "я тут пивасик пойду, посчитай мне"? :)
В сложных случаях получится портянка из колбеков, вложенных друг в друга
Igor
Про толки Нишанова - “C++ Coroutines: Under the covers" (https://www.youtube.com/watch?v=8C8NnE1Dg4A) довольно интересный. Суть его в том что для корутины как правило нужно динамически выделить кусок памяти чтобы хранить state, но в простых случаях где корутина не выходит за пределы функции оптимизатор справляется и дополнительных расходов не возникает. Для stackful так точно не получится, что сделает их использование для разных простых генераторов накладным.
Олександр
А есть где-нибудь обсуждение этой новости?
Было очень бурное обсуждение с петициями где-то полгода назад.
Александр
корутины, концепты.. про метаклассы что-то новое слышно?
Berkus
В винде наоборот. В винапи есть файберы. Всё готово.
впервые вижу человека который использует виндовые файберы. за всю жизнь.
Matway
впервые вижу человека который использует виндовые файберы. за всю жизнь.
Добавь меня в список.
Berkus
корутины, концепты.. про метаклассы что-то новое слышно?
после рефлексии будет слышно. слышно про рефлексию чего?
Matway
В freertos для корутин надо писать извращенный код, в винде тоже надо сильно напрягаться?
В плане многопоточки Винда даёт фору многим, на удивление.
Alexander "SonnySlave"
у рефлексии новая ревизия
vladislav
Никто не подскажет лёгкую либу для парсинга html5/css3?
Danil
Никто не подскажет лёгкую либу для парсинга html5/css3?
https://github.com/lexborisov/myhtml
https://github.com/google/gumbo-parser
Vitaliy
Подскажите, есть ли либа на C/C++ для манипулирования статическими маршрутами на линухе ? Гугл дал только либу для python.
Vitaliy
Благодарю
Anton
В плане многопоточки Винда даёт фору многим, на удивление.
В каком смысле? В чём заключается сравнение реализаций многопоточности на разных платформах? Какие-то особые алгоритмы диспетчеризации, эвристики, etc?
Kirill
Сам следит что как ему разложить в регистры, как спрятать один стек от другого.
О, ты вернулся в чатик :) с возвращением
Andrei
О, ты вернулся в чатик :) с возвращением
Я и не уходил, поглядывал всегда вполглаза. Дел много :)
Matway
В каком смысле? В чём заключается сравнение реализаций многопоточности на разных платформах? Какие-то особые алгоритмы диспетчеризации, эвристики, etc?
Просто ощущения по результатам разработки нагруженных проектов параллельно под несколько систем.
+ Убогий диспетчер потоков в Линуксовом ядре. За последние годы стало получше, но всё равно умирает раньше, чем виндовый
+ IOCP по сравнению с epoll и kqueue просто божественен. Точнее, наоборот - IOCP куда ни шло, но epoll и kqueue - кошмар. Те, кто писал многопоточную асинхронную сеть под Windows, Linux и OS X - поймут.
+ Виндовая библиотека поддержки многопоточности огромна, там есть методы на все случаи жизни. И оно-таки работает, и довольно шустро. Там, где pthreads - это всё, жить гораздо грустнее. А если ещё и напороться на баг в pthreads (привет Apple)...
+ Таки файберы. Виндовые очень даже.
- В W10 сломали диспетчер процессов, он стал глобально-блокирующим. Если поставить компилироваться проект с тысячами файлов, можно распрощаться даже с курсором мыши
Egor
диспетчер исправили вроде?
Andrei
Ты про линукс или про винду?
Matway
Я говорю, стало лучше. Но всё равно отстаёт от диспетчера W7.
Egor
вин10
Matway
А, нет. Не исправили =) Во всяком случае автоапдейты ничего не приносят.
Anton
Просто ощущения по результатам разработки нагруженных проектов параллельно под несколько систем.
+ Убогий диспетчер потоков в Линуксовом ядре. За последние годы стало получше, но всё равно умирает раньше, чем виндовый
+ IOCP по сравнению с epoll и kqueue просто божественен. Точнее, наоборот - IOCP куда ни шло, но epoll и kqueue - кошмар. Те, кто писал многопоточную асинхронную сеть под Windows, Linux и OS X - поймут.
+ Виндовая библиотека поддержки многопоточности огромна, там есть методы на все случаи жизни. И оно-таки работает, и довольно шустро. Там, где pthreads - это всё, жить гораздо грустнее. А если ещё и напороться на баг в pthreads (привет Apple)...
+ Таки файберы. Виндовые очень даже.
- В W10 сломали диспетчер процессов, он стал глобально-блокирующим. Если поставить компилироваться проект с тысячами файлов, можно распрощаться даже с курсором мыши
Понятно. Я разрабатывал нагруженное сетевое только под Linux и один (довольно старый) проект этого класса портировал с WinAPI как раз-таки в pthreads. Работать он стал после портирования заметно шустрее.
А что с диспетчером? Я в потроха не лез, да и как-то не доводилось сталкиваться с тем, что он помирал. Кстати, о каком-то конкретном шедулере речь? Они ж там менялись несколько раз.
Egor
А, нет. Не исправили =) Во всяком случае автоапдейты ничего не приносят.
скорее всего в обновлении новом 1803
Andrei
Собсна, я бы хотел процитировать разработчиков libev:
Andrei
Про epoll
The epoll mechanism deserves honorable mention as the most misdesigned of the more advanced event mechanisms: mere annoyances include silently dropping file descriptors, requiring a system call per change per file descriptor (and unnecessary guessing of parameters), problems with dup, returning before the timeout value, resulting in additional iterations (and only giving 5ms accuracy while select on the same platform gives 0.1ms) and so on. The biggest issue is fork races, however - if a program forks then both parent and child process have to recreate the epoll set, which can take considerable time (one syscall per file descriptor) and is of course hard to detect.
Epoll is also notoriously buggy - embedding epoll fds should work, but of course doesn't, and epoll just loves to report events for totally different file descriptors (even already closed ones, so one cannot even remove them from the set) than registered in the set (especially on SMP systems).
Andrei
И следом про kqueue
Kqueue deserves special mention, as at the time of this writing, it was broken on all BSDs except NetBSD (usually it doesn't work reliably with anything but sockets and pipes, except on Darwin, where of course it's completely useless). Unlike epoll, however, whose brokenness is by design, these kqueue bugs can (and eventually will) be fixed without API changes to existing programs. For this reason it's not being "auto-detected" unless you explicitly specify it in the flags (i.e. using EVBACKEND_KQUEUE) or libev was compiled on a known-to-be-good (-enough) system like NetBSD.
Andrei
На момент 2015 года, когда я ими вплотную занимался, — это было наиболее актуальное состояние. Ощущения у меня были примерно те же.
Anton
Ясно, понятно. Кошмар.
Alexander "SonnySlave"
P0732R0 "Class Types in Non-Type Template Parameters" was unanimously approved by EWG. I hope we could get this in C++20.
Alexander "SonnySlave"
Alexander "SonnySlave"
Так-так, кто у нас здесь на фоточке: Вилли, Луи, вроде как Bryce и ещё кто-то
Andrei
И продакт плейсмент Кока-Колы.
Alexander "SonnySlave"
ахах, да, кстати. Но я из Твиттера выдрал
Alexander "SonnySlave"
https://developers.redhat.com/blog/2018/03/15/gcc-8-usability-improvements/
Stanislav
Alexander "SonnySlave"
а не только вот сейчас. Но и на том спасибо
Vitaliy
А в clang как с этими проблемами дела обстоят ?
Berkus
Alexander "SonnySlave"
А в clang как с этими проблемами дела обстоят ?
из моего опыта - получше у него с сообщениями об ошибках