VirtualBox ничем не лучше HyperV, а даже хуже. Я написал небольшой проверочный код (в цикле SHA256 считает на c# и go). На железе и на HyperV работает примерно одинаково, на VirtualBox в 2 раза медленнее. На WMVare Workstation примерно как на HyperV. Единственное когда VirtalBox может пригодиться — это подключить usb-устройства в виртуалку.
Простите, а как связана поддержка котлина с поддержкой спринга?
Я откуда знаю
На Kotlin нормально разрабатывать можно только с помощью Idea. Community имеет ограничения, причем на интерпрайзные технологии. Вот кстати вспомнил, вначале OSGI была доступна в коммунити, потом перестала. Я честно не слежу что-то там со временем перестало быть бесплатным, и нет нигде гарантии что еще что-то не станет платным. Вот только почему-то вендорлок относится только к майкрософту, хотя все по большому счету пытаются подсадить на свою иглу.
А почему вендорлок только для майкрософт? Да почти все технологии кому-то принадлежат, по факту все равно зависишь от многих и никак не соскочешь. Ну Java opensource, только язык почему-то не очень развивается (по сравнению например с c# или kotlin). KOtlin по сути принадлежит jetbrains и по факту кто им пользуются платят за Idea. Можно перечислять целый день наверное — Apple, Sap, Oracle, IBM, VMWare, Intel и т.д.
Использует, создал из шаблона проект, нажал в браузере F12 и увидел что загрузились mono.js, mono.wasm, Mono.Security.dll, Mono.WebAssembly.Interop.dll
Я там и пробовал вставлять, но сейчас все таки добился чтобы начало выполняться. Оно оказывается начинает работать при -Xmx начиная от 12Гб. В общем на моем компе если заменить на long там где это возможно, то начинает выполняться за 120 сек вместо 105 сек при использовании int.
Я попробовал заменить на long, оно теперь ругается, ждет int. Видать не везде менять надо, изменил только тип массива и теперь оно не запускается с ошибкой «Exception in thread „main“ java.lang.OutOfMemoryError: Java heap space», я хз где чего надо подкрутить.
На c# у меня на Int64 выполнилось за 103 сек, поменял на Int32 и выполнилось за 83 сек, т.е. ускорение есть, но не 2 раза. Вот памяти, логично, использовало в 2 раза меньше. И результат в случае Int32 неправильный.
Вы просто не умеете его готовить. В разработке это мега удобно. Если весь сервис состоит из одного приложения и nginx, то профита наверное не много. Но вот когда сервис состоит из десятка приложений, то докер очень сильно помогает. Можно упаковать все приложения вместе с настройками в контейнеры, написать скрипт, который всё это поднимает и запускать на своем компе. Некоторые разработчики под каждую задачу поднимают новый сервис с нуля, благо это делается одной командой. Далее гитлаб CI — при пуше приложение собирается в контейнеры, поднимается весь сервис из собранных контейнеров и тестируется. После всех действий остаются артефакты, если нужно разобраться в каких-то проблемах, то можно всё это добро поднять прямо на своей тачке. У контейнеров свои имена, благодаря этому каждый контейнер кажется отдельным компьютером и можно поднимать просто кучу сервисов на своем компе, например моделируя горизонтальное масштабирование. Установленные обычном способом приложения часто распиханы по разным каталогам и оставляют свои следы везде где только можно. Докер это проблему решает элегантно — приложение гадит только в примонтированные папки. Благодаря этому можно весь свой локальный сервис забэкапить буквально копированием и поднять в случае чего на другой тачке за считанные минуты.
Вы: При другом await поток также мог измениться.
Я: В доке написано, что при await поток не меняется. Никогда. Кто лжет, дока или вы?
Вы: Я уже ответил ранее, хотите верьте, хотите проверьте.
— Документация: Ключевые слова async и await не вызывают создания дополнительных потоков. Асинхронные методы не требуют многопоточности, поскольку асинхронный метод не выполняется в собственном потоке. Метод выполняется в текущем контексте синхронизации и использует время в потоке, только когда метод активен.
И где тут написано про единственный поток? Вы трактуете документацию как-то неправильно.
А насчет контекста синхронизации забыли прочитать, что в консольном приложении он не используется и в asp.net core решили от него отказаться. До стольки лет дожили, а гуглом пользоваться не научились. Я вам в последний раз поищу. Вот например blog.stephencleary.com/2017/03/aspnetcore-synchronization-context.html
Например там написано:
With the contextless ASP.NET Core approach, when an asynchronous handler resumes execution, a thread is taken from the thread pool and executes the continuation.
На этом я завершаю свое участие. Думаю у вас так и не хватит смелости признаться в своей неправоте.
После await продолжение (continuation) будет выполняться ровно в том потоке, результат которого мы ждем.
Вы же код тот запустили с http? Там выводится разный идентификатор потока, железное доказательоство.
Смиритесь: документация права, а вам должно быть стыдно, что go-шник лучше вас понимает модель асинхронности dotnet.
Слышь дядя! Покажи где я сказал что документация не права? Или я считаю тебя балаболом.
Я с документацией никогда и не спорил, я спорю с тем как вы ее трактуете.
А вторых я не дотнетчик, и нигде об этом не писал. Я ни одной строчки не написал продуктивного кода на c#.
NoTaskRunInside — ровно такой же асинхронный метод, не содержащий внутри Task.Run. Выполняется в том потоке, откуда его вызвали, возвращается в тот же поток. Никакого «исполнения в пуле потоков».
Я другого никогда и не утверждал, этот как раз тот случай когда задачу не нужно выполнять, это тоже самое что и Task.FromResult(). Покажи где я утверждал обратное или я считаю тебя балаболом!
OneThreadOnly — метод, запускающий асинхронно 5(пять) задач, и ожидающий либо завершения первой из них, либо завершения всех. Обратите внимание, ни о каком «пуле потоков» речи не идет, все 5 задач выполняются строго в одном потоке.
Да ничего он не запускает, сначала разберитесь, потом пишите. Это случай аналогичный Task.FromResult(). Кстати вы 100% не этого не знаете, но их нужно избегать, но вы не знаете почему и возможно сейчас полезете в гугл))
Вы если приписываете мне какое-то утверждение, то будьте добры вставить цитату, иначе балабол.
Потокобезопасность означает что объект можно использовать одновременно из разных потоков. Например в пространстве System.Collections.Concurrent есть потокобезпаосные аналоги коллекций из System.Collections. Да короче сами читайте docs.microsoft.com/ru-ru/dotnet/api/system.collections.concurrent?view=netcore-2.2
Но вам это не поможет, горбатого могила исправит.
1. await не порождает потоки.
Я никогда не говорит, что await порождает потоки. Я говорил, что после await продолжение может выполняться в другом потоке. Все задачи выполняются в пуле потоков, напрямую потоки мы не запускаем, даже с помощью Task.Run().
4. Те методы, которые не содержат Task.Run, выполняются в том же потоке, из которого были вызваны.
Эта ваша выдумка. Ожидание не выполняется ни в каком потоке. Смотрите класс TaskCompletionSource например, ожидание можно вообще реализовать без потоков.
Давайте жгите еще, я с радостью в очередной раз скажу, что вы не разбираетесь ни в чем.
То, что вы пишете, прямо противоречит тому, как оно на самом деле работает.
А вы сами проверьте:
Console.WriteLine($"thread {Thread.CurrentThread.ManagedThreadId}");
for (var i = 0; i < 100; i++)
{
var http = new HttpClient();
var r = await http.GetAsync("https://google.com/");
Console.WriteLine($"thread {Thread.CurrentThread.ManagedThreadId}");
}
а потом попробуйте вместо «await http.GetAsync()» использовать «await Task.FromResult(1)» и расскажите нам почему так происходит. У вас есть удивительная способность находить объяснения всему, даже чего вы не знаете. Правда логика в этих объяснениях отсутствует, но зато это весело))
И наконец-то признайтесь что все это время писали чушь.
Если задача что данные приходят откуда то, то и напишите соответствующий код. Вы же написали «val++» остальное нужно дофантозировать. Я тоже сократил немного, хотите большего, включите фантазию))
Я уже ответил ранее, хотите верьте, хотите проверьте.
Там вон целые книги пишут, конечно в статье многого не написано. А я написал самую малую часть того. Все что я напишу в нескольких предложениях — это не будет соответствовать в полной мере тому как оно на самом деле работает.
Я же написал почему конкретно в этом примере так, потому что там используется Task.FromResult(). В реальной программе вместо getData() был бы настоящий i/o метод и все было бы красиво. Вы свой код упростили для демонстрации паттерна, я тоже упростил.
Я откуда знаю
На Kotlin нормально разрабатывать можно только с помощью Idea. Community имеет ограничения, причем на интерпрайзные технологии. Вот кстати вспомнил, вначале OSGI была доступна в коммунити, потом перестала. Я честно не слежу что-то там со временем перестало быть бесплатным, и нет нигде гарантии что еще что-то не станет платным. Вот только почему-то вендорлок относится только к майкрософту, хотя все по большому счету пытаются подсадить на свою иглу.
Это несерьезно!
На c# у меня на Int64 выполнилось за 103 сек, поменял на Int32 и выполнилось за 83 сек, т.е. ускорение есть, но не 2 раза. Вот памяти, логично, использовало в 2 раза меньше. И результат в случае Int32 неправильный.
И где тут написано про единственный поток? Вы трактуете документацию как-то неправильно.
А насчет контекста синхронизации забыли прочитать, что в консольном приложении он не используется и в asp.net core решили от него отказаться. До стольки лет дожили, а гуглом пользоваться не научились. Я вам в последний раз поищу. Вот например blog.stephencleary.com/2017/03/aspnetcore-synchronization-context.html
Например там написано:
На этом я завершаю свое участие. Думаю у вас так и не хватит смелости признаться в своей неправоте.
Вы же код тот запустили с http? Там выводится разный идентификатор потока, железное доказательоство.
Слышь дядя! Покажи где я сказал что документация не права? Или я считаю тебя балаболом.
Я с документацией никогда и не спорил, я спорю с тем как вы ее трактуете.
А вторых я не дотнетчик, и нигде об этом не писал. Я ни одной строчки не написал продуктивного кода на c#.
Я другого никогда и не утверждал, этот как раз тот случай когда задачу не нужно выполнять, это тоже самое что и Task.FromResult(). Покажи где я утверждал обратное или я считаю тебя балаболом!
Да ничего он не запускает, сначала разберитесь, потом пишите. Это случай аналогичный Task.FromResult(). Кстати вы 100% не этого не знаете, но их нужно избегать, но вы не знаете почему и возможно сейчас полезете в гугл))
Вы если приписываете мне какое-то утверждение, то будьте добры вставить цитату, иначе балабол.
Но вам это не поможет, горбатого могила исправит.
Я никогда не говорит, что await порождает потоки. Я говорил, что после await продолжение может выполняться в другом потоке. Все задачи выполняются в пуле потоков, напрямую потоки мы не запускаем, даже с помощью Task.Run().
Эта ваша выдумка. Ожидание не выполняется ни в каком потоке. Смотрите класс TaskCompletionSource например, ожидание можно вообще реализовать без потоков.
Давайте жгите еще, я с радостью в очередной раз скажу, что вы не разбираетесь ни в чем.
А вы сами проверьте:
а потом попробуйте вместо «await http.GetAsync()» использовать «await Task.FromResult(1)» и расскажите нам почему так происходит. У вас есть удивительная способность находить объяснения всему, даже чего вы не знаете. Правда логика в этих объяснениях отсутствует, но зато это весело))
И наконец-то признайтесь что все это время писали чушь.
Там вон целые книги пишут, конечно в статье многого не написано. А я написал самую малую часть того. Все что я напишу в нескольких предложениях — это не будет соответствовать в полной мере тому как оно на самом деле работает.