Если дальше копать - вот метод Add своим именем говорит нам о том, что будет просто добавлен некий диапазон значений в коллекцию. А зачем метод Add возвращает Task-у тогда? Ведь просто добавить в коллекцию это же в чистом виде CPU-bound работа. Где здесь преимущество от использования асинхронности? Ага, оказывается, что добавление сопровождается отправкой. Вот это нарушение SRP. Очень много ХАОСА в таком маленьком фрагменте кода.
Метод Send у Api вызывает метод Add у BatchCollector-а.
А почему я должен искать непосредственно сам этот метод Send (в этом стектрейсе Send-Add нету никакого Send-а - той ключевой логики, о которой клиентский код попросил)
А если размер передаваемой коллекции в метод Add меньше размера batch-а? То никакой отправки и не будет. Ответственность не исполняется.
Параметр items в методе Add вообще не используется.
Люди не могут проверить код, который публикуют на всеобщее обозрение. Я уж молчу про код, который нигде не публикуется. Вот почему так трудно найти нормальных архитекторов - многие начитались SOLID, и решив, что все поняли, начинают писать статьи на хабре. А те кто умеют в дизайн - они не пишут никакие статьи.
HINT: Если не умеете в SOLID, то вот вам совсем детская формулировка: Любой код должен быть спроектирован так, чтобы его было ОЧЕНЬ ЛЕГКО использовать правильно, и ОЧЕНЬ СЛОЖНО использовать неправильно.
Асинхронно значит несколько другое, отсутствие ожидание имеется в наличии и в параллельном коде и в асинхронном))
Все верно, потому что параллельное выполнение - это частный случай асинхронности. Асинхронность - наиболее фундаментальный термин. Почитайте хоть S.Cleary, что-ли. Асинхронность значит ровно то, о чем было написано.
Т.е. в целом речь шла о том что Task и Thread нельзя четко разделить
Все тут можно разделить - у них совершенно разная ответственость, Task - это асинхронная операция (аналог promise-ов из js, или Future из Java/Rust), а Thread - это исполнитель (рабочая лошадка). У вас еще и SOLID-принципы хромают, судя по всему.
Task.Run - запустит задачу параллельно
Никто так не говорит, почитайте отцов-основателей Task-ов и async/await в С# (S.Toub-а, в частности) - говорят "запускается работа асинхронно". И никак иначе, терминологию надо использовать правильную. У вас легкая каша в голове.
А на деле лесом идет beeline cloud практически с такими статьями. Потому что спецов привлекают глубокие статьи от других спецов, а потом можно глянуть где эти другие спецы работают. А тут пока не наблюдается никаких спецов.
Да, запустит асинхронно. Потому что асинхронно значит - с отсутствием ожидания (busy waiting). Если мы берем вторую рабочую лошадку чтобы тянуть телегу (Task.Run), то первая может делать все что захочет (например везти другую телегу, а может и не везти, смотря что требуется). Подтяните своия знания в асинхронности.
Пережиток прошлого у индусов, когда все люди делились на касты, и некоторые одни касты получали преимущество перед другими. Представьте, не повезло родиться не только в небогатой семье, но еще и не в той касте. Вот несправедливость то...
"в средах с высокой конкуренцией, где требуется частая блокировка и разблокировка, System.Threading.Lock снижает издержки на переключение контекста." - Ла ла ла, дай-ка я на хабр напишу ерунды в пятницу...
Вовсе нет, это просто деталь реализации, если бы в шарпе в ArrayPool.Shared все бакеты под все размеры прединициализировались, то память бы сжиралась еще при запуске приложения.
Как я люблю комментарии на хабре, из них знаний получаешь не меньше, чем из самой статьи..
Тут еще термин concurrency с братаном ваших скрипачей дожидается...)
В Rust-е уже есть, более того, каждый его variant может принимать произвольные данные (будь то кортеж, структура или другой enum, да что угодно).
Если дальше копать - вот метод Add своим именем говорит нам о том, что будет просто добавлен некий диапазон значений в коллекцию. А зачем метод Add возвращает Task-у тогда? Ведь просто добавить в коллекцию это же в чистом виде CPU-bound работа. Где здесь преимущество от использования асинхронности? Ага, оказывается, что добавление сопровождается отправкой. Вот это нарушение SRP.
Очень много ХАОСА в таком маленьком фрагменте кода.
Последняя версия - все еще Хреново задизайнено:
Метод Send у Api вызывает метод Add у BatchCollector-а.
А почему я должен искать непосредственно сам этот метод Send (в этом стектрейсе Send-Add нету никакого Send-а - той ключевой логики, о которой клиентский код попросил)
А если размер передаваемой коллекции в метод Add меньше размера batch-а? То никакой отправки и не будет. Ответственность не исполняется.
Параметр items в методе Add вообще не используется.
Люди не могут проверить код, который публикуют на всеобщее обозрение.
Я уж молчу про код, который нигде не публикуется.
Вот почему так трудно найти нормальных архитекторов - многие начитались SOLID, и решив, что все поняли, начинают писать статьи на хабре.
А те кто умеют в дизайн - они не пишут никакие статьи.
HINT: Если не умеете в SOLID, то вот вам совсем детская формулировка:
Любой код должен быть спроектирован так, чтобы его было ОЧЕНЬ ЛЕГКО использовать правильно, и
ОЧЕНЬ СЛОЖНО использовать неправильно.
Все верно, потому что параллельное выполнение - это частный случай асинхронности. Асинхронность - наиболее фундаментальный термин. Почитайте хоть S.Cleary, что-ли.
Асинхронность значит ровно то, о чем было написано.
Все тут можно разделить - у них совершенно разная ответственость, Task - это асинхронная операция (аналог promise-ов из js, или Future из Java/Rust), а Thread - это исполнитель (рабочая лошадка). У вас еще и SOLID-принципы хромают, судя по всему.
Никто так не говорит, почитайте отцов-основателей Task-ов и async/await в С# (S.Toub-а, в частности) - говорят "запускается работа асинхронно". И никак иначе, терминологию надо использовать правильную. У вас легкая каша в голове.
Согласен, что всегда планировщик по-умолчанию, ведь Task.Run - это более consumer-friendly версия аналога Task.Factory.StartNew.
Из кода видно, что TaskScheduler.Default - так что без исключений, абсолютно всегда асинхронный вызов происходит. @nronnie
Дам тебе прозвище Wat-балбес. ))
А на деле лесом идет beeline cloud практически с такими статьями. Потому что спецов привлекают глубокие статьи от других спецов, а потом можно глянуть где эти другие спецы работают. А тут пока не наблюдается никаких спецов.
Да, запустит асинхронно. Потому что асинхронно значит - с отсутствием ожидания (busy waiting). Если мы берем вторую рабочую лошадку чтобы тянуть телегу (Task.Run), то первая может делать все что захочет (например везти другую телегу, а может и не везти, смотря что требуется). Подтяните своия знания в асинхронности.
Пережиток прошлого у индусов, когда все люди делились на касты, и некоторые одни касты получали преимущество перед другими. Представьте, не повезло родиться не только в небогатой семье, но еще и не в той касте. Вот несправедливость то...
"в средах с высокой конкуренцией, где требуется частая блокировка и разблокировка, System.Threading.Lock снижает издержки на переключение контекста." - Ла ла ла, дай-ка я на хабр напишу ерунды в пятницу...
А ещё суффикс service в systemctl командах не обязательно указывать. Так как они предполагаются unit-ами по-умолчанию.
Да это просто ошибка дизайна, слишком уж громкое название - антипаттерн - для обычной ошибки.
Судя по двум последним фото бурого, и фото тощих белых медведей, видимо так и есть :)
Как говорится, "один в поле воин, коли ты упорен и спокоен" ;)
Зачем быть коробочным программистом?
Не, проще зайти в музей в Лондоне и вылить супчик на творение бедняги Ван Гога.
Вовсе нет, это просто деталь реализации, если бы в шарпе в ArrayPool.Shared все бакеты под все размеры прединициализировались, то память бы сжиралась еще при запуске приложения.
Лучше уж и не писать совсем, чем писать такое. Новостей навалом, ищешь, переводишь и кидаешь эту какаху на хабр. Вот и вся ценность такого - ничего.