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

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

Початкова реалізація функції 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 викликається тільки тоді, коли всі задачі були оброблені і черга порожня

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

🤯

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

Не могу смотреть, глаза вытекли)))

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

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

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

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