Виртуальные потоки Java 21 — чувак, где мой lock?

таски с async-await в dotnet-е. Там запретили в async методах использовать lock для решения этой проблемы.

Если быть точным, то не запретили.

Запретили использовать await внутри lock:

async Task<int> DoAsync()
{
	lock (this)
	{
		await Task.Delay(10); // CS1996 Cannot await in the body of a lock statement
	}
	
	return 7;
}

А lock внутри async - пожалуйста:

async Task<int> DoAsync()
{
	await Task.Delay(10);

	lock (this)
	{
		// do something
	}

	await Task.Delay(10);

	return 7;
}

Эксперт IVA Technologies: рынок IT в России совершил впечатляющий рывок

невозможность пробития современной брони

Это тоже, скажем мягко, не аксиома, да и не так, чтобы правда.

Эксперт IVA Technologies: рынок IT в России совершил впечатляющий рывок

Кстати, одно из мнений гласит, что "из-за угла" можно и вручную заряжать, а вот при маневрировании автоматика сильно помогает.

Я к чему?

К тому, что "самая первая претензия" к российским танкам, на деле - весьма дискуссионная тема.

Эксперт IVA Technologies: рынок IT в России совершил впечатляющий рывок

И что, все в один голос клянут проклятый механизм?

Я к тому, что если мнение теоретическое и обывательское (а не, скажем, основанное на работе с анализом кампаний/боевого применения), то почему упускается из виду тот факт, что достаточно популярных мнений (в мире, в том числе) по поводу АЗ/МЗ не одно, а как минимум 3?

Эксперт IVA Technologies: рынок IT в России совершил впечатляющий рывок

В каком полку служили?

Или с топваровских фронтов?

Реквием по SCRUM: всё равно уже хайп прошёл

del

XML must die

Ок, с этим не поспоришь.

Да, тут нужна схема или определение соответствующего типа на языке программирования - что на моём опыте в 99% случаев наличествует.

И вообще - при публикации XML API не публиковать схему - нехорошо.
...но возможно ;)

XML must die

 Чтобы сделать коллекцию, вы просто повторяете тег.

И что вы ожидаете найти в спецификации XSD?

Ну, как ожидаю? Я находил. К примеру, можно найти как описываются повторящиеся элементы и из этого сделать вывод, как наиболее... разумно сериализовать коллекцию. К примеру - практически как в JSON, т.е.

<SomeInstance>
  ...
  <SomeCollectionProperty SomeCollectionAttribute="" AnotherAttribute="">
    <SomeItem />
    <SomeItem />
    <SomeSubTypeItem />
  </SomeCollectionProperty>
  ...
</ SomeInstance>

Хотя, опять же, если вдруг разработчику схемы по каким-либо соображениям приспичило сериализовать так, как описано - нет проблем, будет работать. И даже валидную XSD для такого можно написать.

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

Так я не понял, это сторонняя библиотека требовала на вход такой XML?

Впрочем, не важно, удивление моё адресовано авторам новаторского подхода к сериализации пропертей-коллекций.

Но, повторю ещё раз: и так тоже можно, если очень надо. Просто неоднозначно и странно.

Несколько нелогично, по-моему, упоминать подобное как претензию к XML

XML must die

Это сейчас всерьёз, про коллекции?

Хоть бы в спецификацию xsd кто заглянул, прежде чем... новаторствовать.

Предложенные варианты вообще ни в какие ворота, конечно, НО - они работают, если уж так прям нужно.

Вот скажи мне, микросервис, в чем сила

Expressions медленные
Expression.Lambda - тяжёлая вещь.

Не настолько.
Плюс ламбда в EF не компилируется.

Да и мусор от них вряд ли переживёт ген0 при таком использовании.

Вот скажи мне, микросервис, в чем сила

дел

Вот скажи мне, микросервис, в чем сила

Чисто формально - .НЕТ открытый проект, куда бы МС не ушёл, на возможность пользоваться .НЕТом это не повлияет.

Дальше, .НЕТ - от рантайма-джита, через базовую библиотеку и до дизайна языка и компилятора - громадный и интереснейший кусок знаний (и опыта), развивающийся у нас на глазах.

Так что хотя бы с этой точки зрения должно быть познавательно.

Ну и возвращаясь к уходу МС - было бы, конечно, здорово и интересно всё это импортозаместить - да хотя-бы даже реализовать рантайм-джит для Эльбруса или только MAUI для авроры (или как там её?), но я/ты/он/она такое организовать не потянем, а заинтересованности у тех, кто мог бы, к сожалению, не заметно.
А могло бы стать шагом к какой-нибудь православной хармони-ос.

Конец эпохи YouTube — пора бежать на российские аналоги или почему Rutube того не стоит?

существует большая русскоязычная община в других странах

И вас, судя по всему, могут сильно удивить настроения большой части этой общины

Конец эпохи YouTube — пора бежать на российские аналоги или почему Rutube того не стоит?

Кому и кобыла невеста, конечно

Конец эпохи YouTube — пора бежать на российские аналоги или почему Rutube того не стоит?

обманывать, рассказывать как коварный запад недобро смотрит на нашу беларусь и как плохо живут бомжи в америке.

И что из этого неправда?

ThreadPool – инъекция потоков

Я говорил именно про долгие CPU-bound таски, которые тредпул плохо переваривает.

Так а что имеется ввиду под "плохо переваривает долгие CPU-bound задачи"?

Вообще, долгая CPU-bound - это идеальная задача с точки зрения производительности, часто недостижимая.

ThreadPool – инъекция потоков

О. не туда ответил, оказывается. См. ниже.

https://habr.com/ru/companies/skbkontur/articles/832742/comments/#comment_27113534

ThreadPool – инъекция потоков

Просто утверждение было слишком общее и (как минимум поэтому) слишком некорректное.

С точки зрения перфоманса, несколько долгих задач будут гораздо эффективнее множества коротких - расходы (как процессора, так и памяти) на постановку задачи в очередь, создание стейт-машины, таска, регистрации комплишна, переключение контекста (опционально), GC, чтобы собрать весь этот мусор и ещё множества необходимых операций часто гораздо выше, чем время и ресурсы необходимые на выполнение самой полезной нагрузки.

Так что ещё раз: с точки зрения чистого перфоманса, несколько долгих задач будут гораздо выгоднее множества коротких.

А дальше, конечно, начинаются нюансы - что важнее, пропускная способность, общее время выполнения или "отзывчивость", сколько (много ли) задач нужно создать "авансом" или есть возможность организовать ограниченный буфер создаваемых задач (backpressure) и т.д., и т.п.

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

ThreadPool – инъекция потоков

чем задача дольше, тем хуже это может сказаться на перформансе

А можно немного раскрыть мысль?

Выжимаем из Go максимум производительности

...а где девиртуализация - там и возможный автоматический инлайнинг на уровне JITа.

А где структуры - там и локальность данных.

Нахлынули воспоминания ;)