Я про, то что ещё во многих отраслях используют ANSI C++ и не спешат к новомодным штучкам (иногда для упрощения сопряжения с Си). Т.е. для многих это вполне приемлемый вариант не использовать новые фичи/стандарты. Собственно и khim мог бы просто не использовать async, что бы не боятся на счёт совместимости своих подходов к разработке и технологиями.
Ни в Chromium ни в Firefox такого не нашёл. Но в firefox нашёл версию: пишет 2.0 и в Chrome при помощи плагина отследил наличии http2 сессии и даже смог лог http2 коннекта глянуть.
Так что я думаю всё работает и это без каких либо телодвижений связанных с OpenSSL.
То есть если мне нужно загрузить н ресурсов из сети, мне придется это делать поочереди?
Да, но так как большая часть времени уйдёт на транспорт данных по TCP, ваша программа будет заниматься чем то ещё.
По факту выполнение будет только для пред обработки зарпоса и обработки ответа. При этом не будет происходить вредных контекст свичей ядра ОС.
Нифига себе заявочки. Хорошо что не вы эту фичу пытаетесь в комитет по стандартизации продвигать. Потому что одно такое заявление само по себе было бы достаточно чтобы фичу «зарубить» раз и навсегда. Независимо от каких-либо других аргументов.
Почему?
Ах, вы не знаете и вас это не волнует — ну это ваш выбор.
Я вот даже скорее вот на это ответил. С чего вы решили, что меня не волнует? После такого отношения, мягко говоря не конструктивного так и хочется, что бы эта фича прошла. >_<
«Думаете» или знаете? Или опять: «я хочу эту фичу, что будете делать вы — меня не волнует?»
Oh my god! Я не автор этого пропозла и не автор реализации, я потребитель. О том, что бы эта фича не поломала все остальные компоненты языка должны думать разработчики. Если вдруг технически нельзя безопасно (ничего не поломав) внедрить то я конечно расстроюсь но переживу. С чего вы решили, что я стою на позиции: запихнём эту фичу, а остальное пусть горит синем пламенем?
А мне, как пользователю C++ «на железе» — ни разу.
Ну и используйте C++14 дальше, С++17 никто не заставляет использовать.
Как это взаимодествует с `__thread`? А с `tgkill`/`sigaction`? Что мне потребуется сделать в RTEMS чтобы это использовать? Ах, вы не знаете и вас это не волнует — ну это ваш выбор. Только не суйте это сырое и недодуманное поделие в стандарт.
Думаю особых проблем с этим не будет.
Одно дело — сделать фичу, которая реализуется в виртуальной машине поверх ограниченного рантайма, другое — придумать нечто, что должно работать на всём, начиная со стиральных машин и марсоходов, и кончая суперкомпьютерами.
Именно там асинхроность очень часто встречается. Тут же просто синтаксический сахар, что бы избежать callback-hell.
Всё остальное — это искажения термина и лишь ещё один интерфейс для Thread Pool. Быстрый поиск выдаёт, что в MSVС реализовали таки через треды, что неудивительно.
Тогда мало смысла в этой реализации.
Пробежал глазами упомянутое предложение, не увидел упоминания о потоках, как контролировать всю подноготную runtime в этом контексте.
Кхм… неужели в этом предложении нету описания реализации?
Моё мнение: в корутинах потоков быть не должно. Должен быть диспетчер выполнения кода.
Сопрограммы в стиле C# await — во многом результат простого копирования синтаксиса из других языков. Скопировали и запустили в работу. При этом были скопированы и ошибки и недостатки сопрограмм из этих языков (C#, Python).
А есть гденить конкретика? т.е. какие конкретно ошибки из этих языков были унесены?
В этой критике много воды. Даже не знаю… самое существенное это то, что это инвазивный вариант и лучше было бы назвать служебное слово какнить типо std_await. Мне как пользователю Python который часто мучает Tornado и Asyncio всё кажется логичным.
Данное свойство автоматически создает module definition (.def) со всеми глобальными символами из .obj файла для динамической библиотеки на ОС Windows.
О!!! Спасибо! А то мне сейчас приходится юзать перловый скрипт который создаёт этот .def. Но увы пока приходится использовать 4.3 т.к. в 4.4 отломали MSVC2015.
Вы правы я именно про latency, про такты это привычка. Но вообще просто бывают SIMD которые не особо быстрее обычных операций. Обычно вроде с обычным 32 битным add сравнивают скорость.
Ну там либо от imgtec всеми нелюбимый PowerVR или через PCIe подключено что то. В теории можно было бы Radeon подключить (Rage хотя бы ), благо все драйвера открыты.
К слову, что с GPU? Если есть терминал (на картинке), то какой то вариант там должен быть.
Есть DRM/Mesa модули?
В доках заметил только:
128-bit SIMD – accelerates execution of audio, video, graphics, imaging, speech and other DSP-oriented software algorithms, with instruction set designed for development in high level languages such as C, OpenCL
Эти 128 bit за сколько тактов отрабатывают (понятно, что скорее всего зависит от конкретной команды но всё же)?
Тут скорее не о проблеме выбора, а о том, что все варианты со своими компромиссами. Лично я сейчас в похожей ситуации как автор. Но последнее, что я осилил это на одном проекте отказаться от MochiKit и перейти на VanilaJS. Все модные фреймворки мне категорически не нравятся.
Application-Layer Protocol Negotiation (ALPN) No
Next Protocol Negotiation (NPN) Yes h2 http/1.1
т.е. NPN достаточно кажется для браузеров.
Может это только openssl проблема?
Так что я думаю всё работает и это без каких либо телодвижений связанных с OpenSSL.
Я почти каждый день работаю с Tornado и хорошо понимаю именно их подход, а он именно за ручную асинхронность.
Да, но так как большая часть времени уйдёт на транспорт данных по TCP, ваша программа будет заниматься чем то ещё.
По факту выполнение будет только для пред обработки зарпоса и обработки ответа. При этом не будет происходить вредных контекст свичей ядра ОС.
Почему?
Я вот даже скорее вот на это ответил. С чего вы решили, что меня не волнует? После такого отношения, мягко говоря не конструктивного так и хочется, что бы эта фича прошла. >_<
Oh my god! Я не автор этого пропозла и не автор реализации, я потребитель. О том, что бы эта фича не поломала все остальные компоненты языка должны думать разработчики. Если вдруг технически нельзя безопасно (ничего не поломав) внедрить то я конечно расстроюсь но переживу. С чего вы решили, что я стою на позиции: запихнём эту фичу, а остальное пусть горит синем пламенем?
Ну и используйте C++14 дальше, С++17 никто не заставляет использовать.
Думаю особых проблем с этим не будет.
Именно там асинхроность очень часто встречается. Тут же просто синтаксический сахар, что бы избежать callback-hell.
Тогда мало смысла в этой реализации.
Кхм… неужели в этом предложении нету описания реализации?
Моё мнение: в корутинах потоков быть не должно. Должен быть диспетчер выполнения кода.
А есть гденить конкретика? т.е. какие конкретно ошибки из этих языков были унесены?
В этой критике много воды. Даже не знаю… самое существенное это то, что это инвазивный вариант и лучше было бы назвать служебное слово какнить типо std_await. Мне как пользователю Python который часто мучает Tornado и Asyncio всё кажется логичным.
О!!! Спасибо! А то мне сейчас приходится юзать перловый скрипт который создаёт этот .def. Но увы пока приходится использовать 4.3 т.к. в 4.4 отломали MSVC2015.
Есть DRM/Mesa модули?
В доках заметил только:
Эти 128 bit за сколько тактов отрабатывают (понятно, что скорее всего зависит от конкретной команды но всё же)?