Зачем нам надо обращать внимание на то, кто вызывает функцию Thread.Start
Ну как же, вы утверждаете, что асинхронный код создает потоки. Я же утверждаю, что это не так. Потоки в .NET запускаются чаще всего вызовом именно этого метода, поэтому обратить внимание стоило бы. Я бы на вашем месте обратил.
ну не равно, а что дальше то
Божественная аргументация :) Не думал, что это потребует дополнительных объяснений. Вот, например, есть у вас автомобиль, и вы его используете. У него есть двигатель. Верно ли будет сказать, что вы != двигатель, или вы несогласны? Вот, например, есть ДВС, а есть электродвигатель. ДВС загрязняет окружающую среду. Правда ли то, что если у вас есть автомобиль, вы загрязняете окружающую среду? А если там электродвигатель? А если он просто в гараже стоит?
Я честно говоря думал, что мысль крайне простая и доступная.
Пока не вижу, опять же, что, на практике, зависит от того, считаем мы, что асинхронный код может создавать потоки, или выносим эту функцию на какой-то другой уровень, чем отличается аренда потока от создания
Серьёзно? Вы не видите разницы между арендой потока и созданием? :)
получается, что вы просто хотите проигнорировать эту функциональность, типа: вот тут у меня асинхронный код, а все остальное меня не интересует
Это не совсем так работает. Это называется абстракция и декомпозиция - вот у нас есть контекст синхронизации (это абстракция), он будет отвечать за детали логики выполнения continuation'ов. И да, с точки зрения асинхронного кода то, как это будет происходить - я могу проигнорировать, так же, как это осознанно сделали разработчики .NET. Это значительно упрощает разработку.
Мне кажется, у нас с вами разное представление о том, что такое "асинхронный код" и что значит "создает потоки".
Код, который создает потоки - это код, который явно делает Thread.Start. Создание потоков, кстати, это относительно ресурсоёмкая операция, да и память отжирает понемногу.
Асинхронный код - это какой-то код внутри асинхронного метода с асинхронными вызовами (await), раскладываемый компилятором на стейт-машину.
Так вот, если вы явно не вызываете Thread.Start в своем асинхронном коде - он потоков не создает. Контекст может создавать новые потоки или переиспользовать в ходе выполнения асинхронного метода. Но контекст != асинхронный код. И то, что в каких-то случаях асинхронный код может использовать такой контекст, совершенно не обозначает, что асинхронный код создает потоки.
Грубо говоря, асинхронный метод делится на части и превращается в некоторую стейт машину. Можно сказать, что разделение проходит по await'ам. Т е до первого await'а выполнение происходит синхронно, затем стейт-машина эти кусочки (continuation'ы) по очереди шедулит в synchronization context.
В вашем случае, используется дефолтный контекст, который шедулит continuation'ы на потоки из тред-пула. Более того, вы не await'ите первый вызов, т е делаете fire and forget - глупо ожидать, что две параллельные задачи в таком контексте начнут выполняться на одном потоке.
То есть, эти потоки они уже есть в наличии, и их использование дефолтным контекстом вполне оправданно.
Что касается контекстов UI - ну, во-первых, название метода вообще ни о чем не говорит. Во-вторых, добавьте .ConfigureAwait(false) и получите немалый шанс того, что после этого await'а поток поменяется. Не потому, что кто-то создал новый поток. Просто для continuation'а может быть использован другой контекст - тот же дефолтный, на тред пуле.
У меня стойкое ощущение, что этот комментарий был ответом на что-то другое :)
Тем не менее. Совсем неясно, о каких табличках идет речь. enum в C# в целом используется точно так же, как и в других языках, где он есть. Значение по умолчанию для enum работает точно так же, как и для примитивных типов. Только если вы не путаете enum и Enum, который в чистом виде никто не использует.
Интересный подход, облегчаете задачу критикам. Однако, оригинал и перевод ничем визуально не отличаются, это усложняет чтение. Было бы круто оригинал выделить визуально как-то (например, курсивом) или убрать под спойлер. То же самое касается выделения слов, сильно пестрит - я уверен есть способ, который меньше бросается в глаза.
И все же интересно, как правильно - мультипроцессор или многопроцессор? У вас встречаются оба термина. А перейдя по ссылке в начале статьи увидел "Драйвер уровень" вместо "Уровень драйвера". Думаю в целом с переводами есть еще над чем поработать.
Да нет у меня никакого презрительного отношения, с чего вы это взяли. Каждому разработчику нужен редактор, чтобы редактировать какие-то отдельно взятые файлы (xml, json, или вот GH Actions) - в моем случае, это Notepad++, кто-то в моей команде использует VS Code, кто-то Sublime и т. д. - и это нормально и вопросов здесь никаких нет. Каждому инструменту своя область применения.
Но я пока что-то не вижу чтобы кто-то всерьёз делал крупные C# проекты на VS Code - с нормальным GUI, чтобы 100+ проектов было в солюшне и так далее. Почему-то все используют для этого VS или Rider, загадка правда?
Насколько я понимаю, ваш опыт в этом вопросе исходит из сравнения WebStorm и VS Code в плане разработки на js/ts. Вот честно, на js/ts +- можно хоть в блокноте писать, особенно на js. Так что вполне допускаю, что IDE для js не дает какого-то вау эффекта :)
К сожалению, ничем не могу вам помочь, т. к. на js/ts не разрабатываю и вполне допускаю, что точно зная чего хотите достичь, обвесив VS Code плагинами он может дотянуть до WebStorm'а. Я разрабатываю на C# и немного на C++ и мне после VS, к сожалению, совсем не зашло. Даже с плагинами, и точно зная чего я бы хотел достичь.
Я давать четких определений не буду, но предлагаю сравнить опыт при использовании IDE (такой, как VS) с опытом использования редактора (такого, как VS Code). В первом случае установил - и можешь работать, больше делать ничего не надо, у тебя сразу все есть. Во втором случае - установил, поискал нужные плагины, установил их, настроил, пути прописал ко всяким SDK если не нашлись и т. д. - и все равно результат, как ни крути, до VS не дотягивает. Точно так же можно на vim все это навешать, но почему-то никто не спешит называть vim IDE.
Здесь много нюансов, в основном связанных с нестандартными шрифтами/кодировками и управляющими командами. Вот пример - https://github.com/microsoft/terminal/issues/10362 - это была драма в нескольких действиях в своё время :)
Не баг, а фича
Существует три проблемы программирования:
Именование переменных
Инвалидация кэшей
Групповые операции в плейлистах
Я вот тоже думал, что это шутка такая, а вы по сути что-то такое и утверждаете
Ну как же, вы утверждаете, что асинхронный код создает потоки. Я же утверждаю, что это не так. Потоки в .NET запускаются чаще всего вызовом именно этого метода, поэтому обратить внимание стоило бы. Я бы на вашем месте обратил.
Божественная аргументация :) Не думал, что это потребует дополнительных объяснений. Вот, например, есть у вас автомобиль, и вы его используете. У него есть двигатель. Верно ли будет сказать, что вы != двигатель, или вы несогласны? Вот, например, есть ДВС, а есть электродвигатель. ДВС загрязняет окружающую среду. Правда ли то, что если у вас есть автомобиль, вы загрязняете окружающую среду? А если там электродвигатель? А если он просто в гараже стоит?
Я честно говоря думал, что мысль крайне простая и доступная.
Серьёзно? Вы не видите разницы между арендой потока и созданием? :)
Это не совсем так работает. Это называется абстракция и декомпозиция - вот у нас есть контекст синхронизации (это абстракция), он будет отвечать за детали логики выполнения continuation'ов. И да, с точки зрения асинхронного кода то, как это будет происходить - я могу проигнорировать, так же, как это осознанно сделали разработчики .NET. Это значительно упрощает разработку.
Мне кажется, у нас с вами разное представление о том, что такое "асинхронный код" и что значит "создает потоки".
Код, который создает потоки - это код, который явно делает
Thread.Start. Создание потоков, кстати, это относительно ресурсоёмкая операция, да и память отжирает понемногу.Асинхронный код - это какой-то код внутри асинхронного метода с асинхронными вызовами (await), раскладываемый компилятором на стейт-машину.
Так вот, если вы явно не вызываете
Thread.Startв своем асинхронном коде - он потоков не создает. Контекст может создавать новые потоки или переиспользовать в ходе выполнения асинхронного метода. Но контекст != асинхронный код. И то, что в каких-то случаях асинхронный код может использовать такой контекст, совершенно не обозначает, что асинхронный код создает потоки.Не создает асинхронный код потоки :)
Грубо говоря, асинхронный метод делится на части и превращается в некоторую стейт машину. Можно сказать, что разделение проходит по await'ам. Т е до первого await'а выполнение происходит синхронно, затем стейт-машина эти кусочки (continuation'ы) по очереди шедулит в synchronization context.
В вашем случае, используется дефолтный контекст, который шедулит continuation'ы на потоки из тред-пула. Более того, вы не await'ите первый вызов, т е делаете fire and forget - глупо ожидать, что две параллельные задачи в таком контексте начнут выполняться на одном потоке.
То есть, эти потоки они уже есть в наличии, и их использование дефолтным контекстом вполне оправданно.
Что касается контекстов UI - ну, во-первых, название метода вообще ни о чем не говорит. Во-вторых, добавьте .ConfigureAwait(false) и получите немалый шанс того, что после этого await'а поток поменяется. Не потому, что кто-то создал новый поток. Просто для continuation'а может быть использован другой контекст - тот же дефолтный, на тред пуле.
fasm вроде как и в x86-64 умеет тоже
У меня стойкое ощущение, что этот комментарий был ответом на что-то другое :)
Тем не менее. Совсем неясно, о каких табличках идет речь. enum в C# в целом используется точно так же, как и в других языках, где он есть. Значение по умолчанию для enum работает точно так же, как и для примитивных типов. Только если вы не путаете enum и Enum, который в чистом виде никто не использует.
По-моему Visual Studio имеет community edition и в ней можно писать в том числе и на C.
А можно подробнее про Norton Commander?
https://github.com/dnSpyEx/dnSpy вот такое не пробовали использовать?
Интересный подход, облегчаете задачу критикам. Однако, оригинал и перевод ничем визуально не отличаются, это усложняет чтение. Было бы круто оригинал выделить визуально как-то (например, курсивом) или убрать под спойлер. То же самое касается выделения слов, сильно пестрит - я уверен есть способ, который меньше бросается в глаза.
И все же интересно, как правильно - мультипроцессор или многопроцессор? У вас встречаются оба термина. А перейдя по ссылке в начале статьи увидел "Драйвер уровень" вместо "Уровень драйвера". Думаю в целом с переводами есть еще над чем поработать.
Для заметок действительно подходит Google Keep, для простого планирования и списков задач TickTick бесплатной версии за глаза
Да нет у меня никакого презрительного отношения, с чего вы это взяли. Каждому разработчику нужен редактор, чтобы редактировать какие-то отдельно взятые файлы (xml, json, или вот GH Actions) - в моем случае, это Notepad++, кто-то в моей команде использует VS Code, кто-то Sublime и т. д. - и это нормально и вопросов здесь никаких нет. Каждому инструменту своя область применения.
Но я пока что-то не вижу чтобы кто-то всерьёз делал крупные C# проекты на VS Code - с нормальным GUI, чтобы 100+ проектов было в солюшне и так далее. Почему-то все используют для этого VS или Rider, загадка правда?
Насколько я понимаю, ваш опыт в этом вопросе исходит из сравнения WebStorm и VS Code в плане разработки на js/ts. Вот честно, на js/ts +- можно хоть в блокноте писать, особенно на js. Так что вполне допускаю, что IDE для js не дает какого-то вау эффекта :)
Значит, все же редактор :)
К сожалению, ничем не могу вам помочь, т. к. на js/ts не разрабатываю и вполне допускаю, что точно зная чего хотите достичь, обвесив VS Code плагинами он может дотянуть до WebStorm'а. Я разрабатываю на C# и немного на C++ и мне после VS, к сожалению, совсем не зашло. Даже с плагинами, и точно зная чего я бы хотел достичь.
Я бы не стал спорить с MS на этот счет:
Раз
Два
Я давать четких определений не буду, но предлагаю сравнить опыт при использовании IDE (такой, как VS) с опытом использования редактора (такого, как VS Code). В первом случае установил - и можешь работать, больше делать ничего не надо, у тебя сразу все есть. Во втором случае - установил, поискал нужные плагины, установил их, настроил, пути прописал ко всяким SDK если не нашлись и т. д. - и все равно результат, как ни крути, до VS не дотягивает. Точно так же можно на vim все это навешать, но почему-то никто не спешит называть vim IDE.
Я бы добавил что музыка в игре тоже вносит немалый вклад. ОСТ Quake II очень хорош.
Здесь много нюансов, в основном связанных с нестандартными шрифтами/кодировками и управляющими командами. Вот пример - https://github.com/microsoft/terminal/issues/10362 - это была драма в нескольких действиях в своё время :)
У меня, сестры, бывшей жены и дочки одинаковые инициалы, и фамилия тоже (имена разные). Пока ни одной проблемы.