dzięki za feedback :p

dzięki za komentarz, będzie więcej i to nie tylko z backendu ;p

dzięki za komentarz i gratulacje obrony 👏👏 :) o temat delegat zahaczyłem przy okazji typów generycznych, możesz podejrzeć tutaj: kzfaq.info/get/bejne/bNyWdpdy0ralZIE.html

Eventy raczej nie, a refleksja i atrybuty pewnie się prędzej czy później pojawia :p

Jasne, w programowaniu asynchronicznym głównym celem jest nie blokowanie wątku głównego aplikacji i przy takim podejściu operujemy na Task'ach, które są swego rodzaju abstrakcją wykonania kodu na innym niż głównym wątku - z tym że używając async/await/Task, w żaden sposób sami nie operujemy na wątkach - nie tworzymy ich, nie dbamy o komunikację miedzy wątkami. A z drugiej strony czyli programowanie wielowątkowe, to już jest koncept bardziej niskopoziomowy, gdzie sami 'ręcznie' tworzymy nowe wątki w naszej aplikacji, przekazujemy na nie jakaś prace do wykonania, a następnie musimy zadbać o synchronizację wątków/komunikacje, a po zakończeniu pracy odpowiednio ten wątek zamknąć Czyli w kontekście nie blokowania głównego wątku - programowanie wielowątkowe też możnaby nazwać asynchronicznym - z tym że o wiele bardziej złożonym (i mniej przyjemnym dla programistów ;p)

Jeżeli nie ma założonego locka na ta operacje to teoretycznie jest szansa na taka sytuacje

Dzięki :) jakaś plaga z tymi botami

Hej, tak wszystko powinno być asynchroniczne

Zadanie jest wykonywane przy wywołaniu metody która je zwraca, a błąd jest zwracany w momencie oczekiwania na wynik (zakończenie) zadania

kilka osób pytało mniej więcej o to samo, także pomyślałem, że może nagram o tym video zamiast każdemu z osobna odpisywać, powinno się w krótce pojawić ;p

@@FullstackDeveloperPL Super :D

to zależy czy będziesz chciał tworzyć aplikacje desktopowe w WPF, jeżeli celujesz stricte w programowanie webowe, to nie będzie konieczności nauki Xaml'a

ja osobiście nie pisałem w WinForms, także tutaj ciężko mi pomóc

asynchronicznosc nie polega na uruchamianiu nowym wątków - to się zgadza, a co do " kod wykonuje sie na wielu watkach jedniczesnie", to też się zgadza mimo tego że sami nie tworzymy tych wątków. Korzystając z biblioteki TPL czyli np z metod Task.Start czy Task.Run, to ten kod pod spodem korzysta z ThreadPool'a czyli zasobu który jest przypisany do działającej aplikacji, który w sobie agreguje pule dostępnych wątków. I to własnie na wątkach z tej puli będzie wykonywał się kod asynchroniczny

@@FullstackDeveloperPL blog.stephencleary.com/2013/11/there-is-no-thread.html Znalazlem artykuł w którym jeden z MVC microsoftu opowiada o tym, artykuł jednak mówi, ze threadPool nie bierze udziału w operacji asynch...

​@@tomekxxxj3145 w tym artykule Stephen opisuje konkretny przypadek "If the async operation is pure, then there is no thread." Skopiuj i odpal sobie ten kawałek kodu, ale najpierw zastanów się po tym artykule co byś powiedział że się wypisze w konsoli a później go uruchom: class Program { static async Task Main(string[] args) { Console.WriteLine($"{Thread.CurrentThread.ManagedThreadId} {Thread.CurrentThread.IsThreadPoolThread} "); await Foo(); } static async Task Foo() { await Task.Delay(500); //some async code Console.WriteLine($"Foo: {Thread.CurrentThread.ManagedThreadId} {Thread.CurrentThread.IsThreadPoolThread} "); } } A jak już wspomnieliśmy o Stephenie, to jeżeli chcesz wiecej o asynchronicznosci i kodzie wielowątkowym poczytać to polecam jego ksiązke 'Concurrency in C# Cookbook'

@@FullstackDeveloperPL a co to wgl znaczy ze jest czysta, jakos z internetowych zrodel nie moge troche zrozumieć, chyba jeszcze nie moj level... Jakos prostymi slowami bys mogl? :) Pzdr

@@tomekxxxj3145 w kontekście tego artykułu to odnosił się on do operacji związanych z wejściem/wyjściem - nie ma tutaj pracy procesora przez co nie ma potrzeby na osobny wątek. Dlatego też kod nie jest blokowany (jest asynchroniczny), a jego wykonywanie zostanie wznowione dopiero po otrzymaniu sygnału zakończenia operacji wejścia/wyjścia

Apka o nazwie zoomit