Конкурентная асинхронная очередь на JavaScript

[@TimurSevimli]

Спасибо большое за лекцию Тимур Гафарович! После лекции голова разболелась 😅

[@СергейДидковский-ч6в]

Для очереди лучше использовать pop + unshift чем shift + push. pop забирает только последний элемент, shift - двигает все. Важно, чтобы очередь могла быстро очищаться. Разница в производительности может быть на пару порядков.

[@TimurShemsedinov]

В js массивы сделаны как списки, поэтому, скорее всего, разницы ни какой, в списках элементы не передвигаются. Но без эксперимента это нельзя утверждать. Да и то, эксперимент не будет иметь силы, как только обновится витуальная машина js. В нашем случае это v8, а мы знаем, что v8, это просто библиотека всяческих оптимизаций и неочевидных вещей, и может менять свое поведение не так, как мы этого ожидаем.

[@СергейДидковский-ч6в]

@@TimurShemsedinov Тестировал в реализации очереди - быстрее, значительно. Честно сказать, заметил совершенно случайно, но эффект оказался значимым.

[@oleg_shulga]

Спасибо, отличное видео.

[@taras7844]

Початкова реалізація функції drain призводить до того, що функція викликається кожного разу, коли оброблюється завдання і зменшується count задач до 0. Це означає, що коли є задачі у черзі, які ще не були взяті на виконання, а поточна задача завершилась, функція drain все одно буде викликана. Тому у вашому виводі в консоль drain друкується після кожної завершеної задачі. Проблема пов'язана з тим, що функція drain спрацьовує не тільки тоді, коли всі задачі в черзі були виконані, але й кожного разу, коли завершується обробка окремої задачі. Очікувана поведінка для функції drain, як правило, полягає в тому, що вона повинна викликатися лише один раз, коли всі задачі в черзі були виконані. finish(err, res) { const { onFailure, onSuccess, onDone, onDrain } = this; if (err) { if (onFailure) onFailure(err, res); } else if (onSuccess) { onSuccess(res); } if (onDone) onDone(err, res); if (this.count === 0 && this.waiting.length === 0 && onDrain) onDrain(); } drain викликається тільки тоді, коли всі задачі були оброблені і черга порожня

[@drmonochromer]

Спасибо! А какие есть способы ограничения непрерывного заполнения очереди ожидания `waiting`? Например, мне нужно обрабатывать файлы, ссылки на которые прилетают из стороннего Readable Stream.

[@TimurShemsedinov]

Асинхронная очередь или семафор со счетчиком

[@HelloGoodbye-f6q]

🤯

[@TimurSevimli]

Я повторно смотрю лекцию и возникло такой вопрос. Как мы можем конкретно определится какое количества каналов требует наша приложение что бы не перегружалась ?

[@TimurShemsedinov]

К сожалению опытным путем и интуицией

[@igorsavelev9013]

а есть где-то в лекциях пример использования данной абстракции?

[@TimurSevimli]

Однажды писал web-scraper и хотел что бы он параллельно собирал данные из сайтов которые передано. Сделал параллельно что бы не ожидать отработку каждого запроса что бы отправить новый запрос. Но в этом случае столкнулся что одно временно отправлялась очень много запросов и из за такого большого обьема ожидании ответов я не мог получать ответ от серверов. Пришлось брать готовую библиотеку из npm и ограничить отработку именно как в этой лекции, так как не знал такие вещи как конкурентных очередей. Но еще в конце лекции рассказываются тоже примеры.

[@dimitro.cardellini]

Одже ... 1. з таймоутом на onProcess без abortController-а все погано. Таска все одно виконається, але замість результатів прилетить timeout error. У випадку, коли йде лише читання, то прзведе до тимчасового використання зайвих ресурсів, що потім прибере коллектор (проте, якщо криво працює сама onProcess, то може і не прибере). У випадку запису даних, то все може будти пагано, і у подальшому вимагати втручання людей до вирішення ситуації (от платіж у нвс затаймаутився, а ми просто не сказали, що він пройшов, а гроші списались, а ордер не підтверджено). Я б все ж таки з черги би цю функціональність прибрав би. Не може черга коректно цей timeout опрацювати 2. спроба відрефакторити той код, навела мене на думку, що все ж таки там вирішується дві задачі одразу: Задача #1: керування черговістю викликів функції onProcessи (власне побудова такої черги, пріоритиети, фактори, таймаут очікування і тп) Задача #2: нагляд за асінхронною функцією (observation over the async function) Власне тому, що дві задачі -- то ця реалізація Concurrent Queue не дорівнює Observables. Обидві задачі окремо вирішуються створенням декораторів для асинхроних функцій, а вся задача -- композиціює цих декораторів І про код. Там є пулл, що відокремлює білдер та власне чергу -- дуже раджу його роздивитись та використати. Краще мати дві прості речі, ніж одну складну.

[@taras7844]

Тайм коди: 01:50 - Інтродукція до асинхронної черги 10:15 - Розширюємо функціональність: додавання таймаутів до черги 24:28 - Керування потоком: додавання паузи та відновлення 30:51 - Підтримка пріоритетів: як розподіляти завдання за пріоритетом 35:00 - Розробка методу pipe для керування потоком даних 42:25 - Ідеї для подальшого розвитку: як ще можна розширити нашу асинхронну чергу"