• 0

    Нет, асинхронность может существовать там, где нет никакого event loop'а. Ведь ничто не мешает передать в любой поток коллбэк, который будет вызван, как что-нибудь произошло.


    Кооперативная многозадачность решённая через event loop просто порождает асинхронность, а не является ей. Асинхронность — просто абстрактное понятие, описывающее процессы, которые происходят не мгновенно.

    Конкурентность: Асинхронность
  • 0

    Написал «а внутрь неё подаётся получившееся R, либо возбуждается исключение E», но не уточнил, что исключение прямо внутри корутины возникает, ну и примера нет, спасибо.

    Конкурентность: Асинхронность
  • 0

    Тут важно ещё понимать, что «обращение к БД» в основном… не происходит, мы почти всё время просто ждём. Записать/прочитать данные в буффер и отправить его сетевой карте — это относительно быстрая операция, относительно времени, которое проходит между такими операциями. И если у нас времени ожидания достаточно, чтобы ещё повычислять чего-нибудь другого — нам не нужен ещё один поток.

    Конкурентность: Асинхронность
  • 0

    Первое зависит от реализации. Платформа, предоставляющая event loop и асинхронное API действительно может создать сколько угодно других потоков и просто перекидывать данные оттуда в «наш главный». Но по факту новые потоки нужны только если что-то действительно вычисляем, опросить состояние IO (пример с БД) можно и в том же самом. А как там ОС это проворачивает — неизвестно, может у неё отдельный поток тоже для всего IO, я не знаю.


    Второе: да, то же самое микропереключение. Только всё состояние живёт в замыканиях функций. Что, по сути, ничем не отличается от поточного контекста. Т.е. если бы мы это делали там, где нет замыканий, нам пришлось бы в функции, запрашивающие старта асинхронной операции, передавать не только коллбэк, но и какой-то объект контекста, который будет передан этому обработчику во время его вызова.

    Конкурентность: Асинхронность
  • 0
    Обязательно должны быть те, кто будет ревьювить код, вносимый в настолько важный проект и иметь права на блокирование внесения некоторых коммитов. Иначе шансы на получение бэкдоров/прочих радостей значительно возрастают, чего не хотелось бы.

    Я не знаю, как на самом деле устроено ядро и мне вот интересно, почему в ядре настолько много работы и из-за чего её объём может расти? Почему не «закончить» разработку ядра, оставив в нём только совсем стабильные системные абстракции, поддерживать «околоядро», предоставляющее API для взаимодействия модулей, а поддержку оборудования вообще вынести за его пределы? Или оно так и есть? Как оно вообще?
    Мейнтейнеры не масштабируются
  • 0
    Выглядит так, будто бы оно просто распарсивает функцию и делает из неё генератор.

    Почему они с тем же успехом не могли распарсивать функцию и впиливать поддержку await/async? Если это так хочется делать в рантайме, а не транспилировать.
    Еще один велосипед для борьбы с callback hell в JavaScript
  • 0
    Лично по мне, пока ты не объяснил какую-либо технологию кому-нибудь ещё — ты её сам не понимаешь.

    Я вот пока не написал эту статью, очень смутно представлял, как работают lock-free алгоритмы, хотя сам порой использовал какую-нибудь джавовую ConcurrentLinkedQueue.

    А сейчас догнал, что они действительно lock-free, но не прям совсем так, чтобы не было блокировок — просто они не используются для блоков кода в принципе, алгоритм используя только атомарные переменные в цикле пытается применить некую операцию до тех пор, пока у него не получится (для добавления в очередь, например, это может быть просто CAS хвоста в цикле, если успеем заменить его до того, как успел кто-то другой — то и славно).

    Ну а wait-free — это характеристика lock-free алгоритма, при которой есть гарантии, что, например, для нашего примера очереди, мы не будем крутиться в цикле вечно (т.е. если все подряд кроме нас будут успевать поменять хвост, а нам постоянно будет не везти) — т.е. гарантии того, что есть какое-то конечное время (возможно зависящее от размера структуры данных/количества одновременных её пользователей), за которое мы успешно совершим некую операцию.
    Конкурентность: Параллелизм
  • 0
    Совсем для новичков я ещё когда-то писал Code Hardcorius, но то было довольно давно и мне там уже много чего не нравится (про полиморфизм вообще дичь какая-то несуразная).
    Конкурентность: Кооперативность
  • 0
    1. Да, некорректно, просто не нашёл другого короткого понятия. Тут я имею в виду, что в случае с данной реализацией промисов всё сделано так, что можно сразу нескольким обработчикам дожидаться результата промиса. И метод .then там это примерно «если промис ещё резолвится, сделай addThenListener(callback), а если зарезолвен, то сделай callback(data)». Да, совсем не PubSub, чистые события.
    2. Промисы реализует кто как хочет, они действительно везде есть, но я хочу показать один из примеров, как их реализовывать не стоит (хотя некоторые плюсы всё же есть, о них тоже расскажу).
    3. Я расскажу о том, как работают обещания перед тем, как будет про async/await, всё будет ок.


    Удалил вообще из содержания пункт про Promises/A+.
    Конкурентность: Параллелизм
  • 0
    Не упоминал про неё, ибо подумал, что она совсем уж микропараллельна, спасибо.

    Ещё про GPU ничего не сказал, хотя там параллельность так параллельность (в которых сотни ядер). Но оно специфично относительно мощных вычислений, а мне бы просто за событиями смотреть и байты туда-сюда копировать.
    Конкурентность: Параллелизм
  • –2
    Да, так и есть. Но ничто не мешает конкурентным процессам выполняться одновременно. Поэтому я всё-таки считаю, что параллелизм это одна из возможных оптимизаций конкурентных подходов, которые существуют вне зависимости от того, есть ли у нас возможность выполнять что-то параллельно на самом деле или нет.

    Абсолютно любой многопоточный алгоритм можно переписать в кооперативном стиле, когда код каждого потока будет делать явные yield'ы, чтобы передать управление другому потоку. Или выполнять код в виртуальной машине, считая операции (так, например, в Erlang'е работают их сверхлёгкие процессы).

    А когда у нас появляется многопоточность — наши подходы никак не меняются и в основном мы просто создаём столько потоков, сколько у нас логических ядер, и в них выполняем функции, которые берём с какой-нибудь очереди задач. В которую кладём обработчики разных событий, которые возникают от асинхронного I/O.

    (а синхронный I/O вряд ли уже кто использует, но его можно реализовать и без параллельного выполнения, достаточно в цикле проверять, есть ли данные, не блокируя, и передавать выполнение другому потоку, если данных нет)
    Конкурентность: Параллелизм
  • 0
    Посмотрел, очень интересно, явное всегда лучше неявного. Спасибо большое, мне нравится этот подход, посмотрим как-нибудь.
    Путеводитель по JavaScript Promise для новичков
  • 0
    Да, так и есть, нужно будет делать что-то вроде .then(checkedForCancel(function(data) { ... })), где checkedForCancel будет возвращать функцию, которая будет проверять какую-нибудь переменную, и только если она всё ещё хорошая, выполнять переданную.
    Путеводитель по JavaScript Promise для новичков
  • 0
    > Тут пользователь снова жмёт «удалить», очень резко, настолько резко

    Опечатка, жмёт «отменить удаление».
    Путеводитель по JavaScript Promise для новичков
  • 0
    Эти ребята никак не могут определиться, как всё-таки правильно отменять промисы. Например, делаем одностраничное приложение, экран открытия какого-нибудь контента. Начали с промиса отправки запроса на сервер с запросом данных и закончили отрисовкой этого всего, накинув кучу then'ов, которые там внутри умудряются пять раз перепотрошить полученный контент, нарендерить двадцать шаблонов и чёрт знает что ещё.

    Всё это дело понеслось, а тут пользователь нажимает на ссылку, старый контент уже никому не нужен, нужно загружать новый. Окей, создаём новый промис, повторяем накидывание обработчиков. Постойте-ка, у нас в процессе выполнения старый. И тут оказывается, что у Promises/A+ нет никаких вариантов обработки отмены промиса.

    Нам остаётся три пути:

    • В каждом обработчике проверять, а не устарел ли запрос на действие, может результат уже никому не нужен.
    • Сделать так, чтобы результат выполнения ВСЕГО промиса был проигнорирован (хотя и выполнен).
    • Использовать 3rd party промисы или пилить свои.


    Пока не особо думал об этом, на данный момент отошёл от промисов, давно не использовал, но пока выглядит так, что отмена должна найти стык, где промис ещё в процессе резолвинга, подменить ему then'ы на пустышки, и послать внутрь самого промиса сигнал отмены, который он может обработать, чтобы прекратить своё выполнение, если может (к примеру, если там промис, который просто спит сколько-то времени, то в обработчике отмены он может просто сделать clearTimeout).

    Это всё ещё можно снабдить специальным сахаром для обработки отмен, чтобы можно было обрамлять некоторые куски цепочки операций, чтобы обрабатывать некоторые специфические случаи.

    К примеру, есть метод, удаляющий некий item, возвращающий промис о завершении. Внутри он отправляет запрос на сервер, плюс делает какие-то действия с моделью. Пользователь жмёт «удалить», метод вызывается, промис начинает работу. Тут пользователь снова жмёт «удалить», очень резко, настолько резко, что запрос даже не успел уйти на сервер (окей, может, у нас есть какая-нибудь логика группировки запросов, или окна общения с сервером, поэтому он не уходит сразу). Тогда мы должны отменить промис удаления. Но произвёв отмену, нам бы хорошо знать, ушёл запрос на сервер или нет. Поэтому мы можем вставить в место, где совершается непосредственно запрос, специальный обработчик, например, .onCancel, который вызовется только когда чейн промисов в состоянии отмены и в него передастся, какое состояние у промиса, на который он непосредственно был накинут (т.е. начал он резолвится или ещё нет). Где каким-то образом куда-нибудь сообщим, что да как. И, например, если запрос уже ушёл, то нам нужно посылать второй в догонку, мол, «сервер, пользователь передумал это удалять, верни как было, пожалуйста».

    Я пока не могу придумать, как можно типизированно сделать, чтобы тот, кто инициировал отмену мог подоставать данные из этих обработчиков с любой глубины, ибо структура чейна промисов может быть совсем любая, и мы не всегда сможем сказать, какие данные наши, какие не наши (например, если в чейне делается несколько запросов, у всех из которых есть обработчики отмены, генерирующие данные, мы отменяем чейн и хотим в результатате операции отмены знать результат отмены конкретного типа запроса). Пока думается, что можно при инициации отмены передавать таблицу Symbol→обработчик, а потом очень аккуратно и обдуманно в обработчиках отмен посылать туда данные, если в сигнале отмены в таблице присутствует некоторый символ.

    Ох, что-то случайно прорвало.
    Путеводитель по JavaScript Promise для новичков
  • 0
    Как запросов будет всё больше, кто-нибудь да заметит даунтайм.

    Я бы подумал, как бы делать всё это дело бесшовно. На вскидку:

    1. Делаем так, чтобы могло работать два экземпляра сервера одновременно (проблемы в данном случае, как я понимаю, могут быть в основном из-за эксклюзивного доступа к файлам, в которые пишите)
    2. Запускаем приложение на каком-нибудь левом порту, например, 8001
    3. Настраиваем iptables на форвардинг 80 → 8001
    4. Когда хотим обновиться, поднимаем второй экземпляр, например, на порту 8002
    5. Перенастраиваем iptables на форвардинг 80 → 8002
    6. Посылаем первому экземпляру сигнал на завершение, на который оно должно дообработать текущие запросы, а больше и не придёт.
    7. Done.


    Тут главное разобраться с iptables, чтобы оно случайно на половине TCP соединения не стало пакеты перебрасывать, а только новые. Если нельзя так — придётся свой роутер пилить.
    12 млрд реквестов в месяц за 120$ на java
  • 0
    Деплоитесь всё так же? kill, restart?
    12 млрд реквестов в месяц за 120$ на java
  • 0
    О да. Я не особо осилил лексеры/парсеры, а как увидел PEG — влюбился в них.

    Вот, например, можно потыкать онлайн — http://pegjs.org/online.
    Пишем свой язык программирования без мам, пап и бизонов. Часть 0: теория
  • 0
    Это проблемы недостаточной проницательности компиляторов. Можно без проблем написать на ФП тот же квиксорт, который будет работать с вектором и использовать только операции перестановки элементов местами. Компилятор должен увидеть, что копий массива не создаётся и что можно использовать тот же самый.

    С хештаблицами то же самое. Это лишь массив списков. Если компилятор сможет увидеть, что к старым версиям таблицы не обращаются и существует только одна последняя — нет проблемы сгенерировать код равный императивному.

    Со слабыми хештаблицами сложнее, ибо в ФП нет никакой памяти, объектов по указателям, ибо мы от всего этого абстрагировались. Нужно или вручную, или вводить в ЯП тип объектов, держащих значения, плюс тип слабых ссылок, конструктор которого принимает объект и любое значение и функцию, которая будет должна подменить значение и заменить следящий объект, если объект подвергается сборке мусора. Тогда делаем список на этих слабых ссылках, указывая фактором разрушения объект, хранящиеся в следующем элементе. Как вызывается коллбек — выбрасываем звено с этим объектом.
    Недостатки чистого функционального программирования
  • +1
    Функция с побочными эффектами это функция, принимающая значение состояния нашей Вселенной и возвращающая некий результат, плюс новое состояние Вселенной.

    Доказывать то, что некие данные появились из I/O, а не от балды легко — ввести типов вроде IsStringFromStdin, значения которых будут возвращаться только из встроенных функций для работы с I/O. С гарантиями записи так же.

    В итоге программа будет являться отображением Вселенной во Вселенную, плюс кучей типов вроде ВЭтойВселеннойБылОткрытПорт(80) и ДляПотокаБайтБылИспользованПарсер(html), ЕслиОткрывалиФайлПоЗапросуАЕгоНетВернулиHTTP404 и так далее (хотя я на самом деле этого не представляю, никто в жизни не сможет формально описать программу целиком, только её основные части).

    Входящие данные обрабатываются так же как и обычно. Просто функция сравнения, например, возвращает не Boolean, а тип-сумму из доказательства или опровержения равенства. А дальше обычный switch и две ветки исполнения.
    Алан Кэй, создатель ООП, про разработку, Лисп и ООП
  • +3
    Вот сидите вы в своём энтерпрайзе глухо, десятками лет оттачиваете навыки джавы/шарпов, ходите на конференции, разрабатываете серьёзные системы и считаете, что всё так и будет и дальше, куда может деться спокойное энтерпрайзное программирование? 50 лет стояло — ещё 50 простоит.

    Но я уверен, что беда придёт откуда не ждали. Функциональное программирование медленно, но верно просачивается всюду, пускает свои ростки. Вы смотрите, уже и в джаве наступает время конкурентности, а не параллельности. И лямбды, мапы, фильтры и, страшно подумать… свёртки списков!

    Сейчас оно проникнет в мейнстрим и люди начнут массово мыслить «функционально».

    И тут всплывёт вопрос типизации. Вот вы говорите, что язык должен быть статически типизирован. Что если я скажу вам, что с моей точки зрения типизация джавы — какое-то ребячество, позволяющее только отличить строку от числа?

    Полиморфная типизация уступает зависимой в бесконечность раз. Языки, поддерживающие зависимые типы (Coq, Adga, Idris) пока только зарождаются и пока выглядят очень плохо и хило. Но есть ребята, которые двигают HoTT и в процессе формализации HoTT в HoTT получат нечто божественное.

    А затем окажется, что можно один раз написать формально верифицированный код и… цена его поддержки равна нулю. В нём guaranteed by math нет багов и он работает согласно спецификации, и как бонус — в нём нет ни одной излишней динамической проверки и он работает быстрее любого си-кода, который написан человеком.

    И тогда будет лишь два вида разработки — «серьёзная», где требуется надёжность. И «несерьёзная» — где можно тяп-ляп и на динамическом ЯП быстро заставить машину сделать чего нужно.

    Языки «среднего класса» умрут.
    Алан Кэй, создатель ООП, про разработку, Лисп и ООП
  • +6
    Хранить бэкапы в том же датацентре — как-то неправильно.
    Изъяты серверы крупного регистратора NIC.UA
  • 0
    WhatsApp на джаббере, вроде как.
    Нам нужны мессенджеры. Ещё больше мессенджеров
  • +1
    Но да, это не решение проблемы. Транспорты всё равно требуют существования аккаунта на чужеземном сервисе и шумят.

    Тут нужно использовать терроризм в больших масштабах, чтобы заставить создателей мессенджеров общаться между собой. Чтобы им было невыгодно не предоставлять такой возможности.
    Нам нужны мессенджеры. Ещё больше мессенджеров
  • 0
    Если эти боты будут причинять много насилия мессенджерам, то их или начнут банить, или выкатят апи для интеркоммуникации.

    QIP Infium во-первых просто поддерживал и jabber и аську. А вот у джаббера были божественные транспорты, через которые и icq, и ВК, и всё что угодно можно было подключить, если такой есть. И транспорты генерировали отдельные контакты, что делало общение совсем бесшовным.
    Нам нужны мессенджеры. Ещё больше мессенджеров
  • 0
    Можно сделать сервис хотя бы для аггрегации контактов. Чтобы он запилил какую-нибудь хорошую систему адресации и имел ботов во всех распространённых мессенджерах.

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

    Затем когда кто-нибудь хочет обратиться к кому-нибудь — может попросить бота переключиться в режим чата с указанным адресом. Другой стороне на главный мессенджер приходит сообщение. Через какое-то время, если оно не было доставлено — уведомления на все остальные.

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

    Костыль, конечно, да и сложно распространить серьёзно.
    Нам нужны мессенджеры. Ещё больше мессенджеров
  • 0
    Случай с копированием списка странноват, вообще говоря.

    PHF не используются в рантайме. Они используются во времени компиляции, чтобы дико оптимизировать словари. Например, когда мы делаем switch-case по строкам не нужно делать O(N), проходясь по каждой строке и сравнивая её с данной, либо считать хэш от всех байт переданной строки. Достаточно найти PHF от case'овых строк, который будет смотреть всего парочку бит, которые уникально характеризуют каждую из строк, узнавать, на какую похожа переданная, а затем сравнивать их (вдруг переданная не из нашего множества вообще).
    Совсем просто про минимальное идеальное хеширование, основанное на графах
  • 0
    Нет, это горизонтальное масштабирование, а не BigData.
    Стоит ли и дальше использовать термин Big Data?
  • 0
    А можно создать устройство, которое бы определяло, что ток идёт неправильно и крутило бы ротор, который бы замыкал контакты наоборот?
    Защита устройств от неправильной подачи полярности питания
  • +3
    Когда Express запретил мне модифицировать какое-то поле (не помню уже) запроса/ответа просто так на ровном месте, никак его не используя, перешёл на Connect (и то, местами всё равно не понимал, зачем у Connect'а там так много кода), реализовав все middleware'и, которые были нужны за какой-то час/два.

    И расширение routing, в котором роутинг делится на статический и динамический. Если дают строку — значит статический, можно просто положить в хештабличку, если регексп — динамический, кладём в список.

    Говорим, что статические доминируют над динамическими by design, как приходит запрос — сначала смотрим по табличке, а затем уже матчим по всем регекспам подряд (было бы ещё дико круто написать/найти библиотеку, которая могла бы взять группу регекспов и по нюансам их работы сделала бы один-несколько, которые бы работали эффективнее).

    И всё это происходит в одном middleware'е, зачем обходить список рекурсивно и плодить их?

    Хотя я знатный велосипедостроитель, сейчас пишу своё асинхронное I/O на восьмой джаве, чтобы написать свой асинхронный HTTP сервер/клиент, подобный нодовскому, с хорошим API, а не этим безобразным сервлетовским наследием.
    Node.js в огне
  • 0
    Теорем, очевидно, бесконечно много. Положим, мы начали искать доказательство некой теоремы A. И мы не знаем, точно ли существует её доказательство. В случае, если доказательства нет, поиск никогда не завершится. Проблема останова является неразрешимой проблемой. Т.е. автоматический вывод теоремы является алгоритмически неразрешимой задачей.

    Даже если искать «или доказательство, или опровержение» у нас есть проблемы с тем, что существуют ещё и вообще недоказуемые теоремы и мы не можем быть уверены, что наша не будет относиться к ним.

    Так что возможно, просто алгоритмически неразрешимо.
    Гарри Каспаров проиграл суперкомпьютеру Deep Blue в шахматы из-за компьютерного сбоя
  • +1
    Highscreen Boost I/II (SE).
    Камера смартфона и трудности компоновки
  • 0
    Буду пользоваться QWERTY/ЙЦУКЕН вплоть до самого прихода нейроконтроллеров. Ну или если «диковинная» клавиатура совершенно случайно окажется в руках, будет совершенно совместима со всеми устройствами и сильно понравится.
    Клавиатура нового поколения — «10-Ю»
  • 0
    По поводу эфективности… а оценка имеет наименьшую дисперсию в классе несмещённых оценок?

    Такое ощущение, что вовсе нет.
    Эффективная оценка медианы
  • 0
    Интересно было бы посмотреть на использование asm.js для этих целей.

    Хотя его поддерживает пока похоже только Firefox, у хрома свой несовместимый NaCl.
    Разбор RAW в браузере: как мы это делали
  • +6
    Лично я за то, чтобы никаких регуляций ни в интернете, ни в реальном мире не было. Единственное, что можно оставить — запрет на насилие (сюда же DDoS-атаки) и гарантии исполнения формальных договоров.

    Интернет — это просто средство передачи пакетов данных, несущих какую-то информацию. Информация должна быть свободна, любое вмешательство в эти данные — зло. А те кто пытаются бороться с информацией обычно воюют со следствием, а не причинами.
    Какие требования сегодня могут быть выдвинуты и озвучены айтишниками?
  • 0
    Интересно, в сообществе сантехников тоже обсуждают как круто было бы, если бы сантехник пришёл к власти?
    Gmail и Skype грозит запрещение в России. А также остальным email и IM сервисам
  • +1
    Ионные двигатели нужны, чтобы мог медленно корректировать орбиту и на каком-то заходе подбирать нужный мусор.
    Проблема космического мусора
  • +1
    image

    Это не глобальный, а для каждого файла в отдельности, если у меня десятки тысяч не сильно больших файлов — он бесполезен.
    Как я использовал BitTorrent Sync между офисами в РФ и Китае