Сообщение Re[9]: Зачем нам асинхронность? от 09.08.2020 8:09
Изменено 09.08.2020 13:40 Serginio1
Re[9]: Зачем нам асинхронность?
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
S>>>>Вместо awaite File.ReadAllTextAsync нужно создавать бэкграунд поток, передавать в него метод в котором вызывать в итоге File.ReadAllText
_>>>Потому что для однопользовательского случая такая задача масштабируется гораздо лучше.
S>> И чем это лучше? Ты запускаешь отдельный поток. Который нихрена не делает, только ожидает когда данные считаются.
_>И в чём проблема с этим? ) Речь же не про тысячу таких потоков, а про один. )
Ты так и не ответил чем лучше?
S>>При этом морозит вспомогательный поток через объекты синхронизации до получения данных.
_>С чего бы это?
S>> При awaite File.ReadAllTextAsync данные передаются сразу в главный поток или если использовать .ConfigureAwaite(false) в любой поток.
S>> Чем это маштабируется то лучше?
_>Потому что помимо просто чтения файла в реальном мире у тебя будет ещё и какая-то его минимальная обработка. Например его парсинг. Если использовать твою схему с awaite File.ReadAllTextAsync, где по твоему будет происходить обработка? Если изначальный вызов был у тебя в UI потоке, то и обработка пойдёт там же. И это даже будет нормально работать у тебя на небольших файликах. А потом пользователь загрузит туда гигабайтный файл и всё твоё приложение зависнет на неопределённое время. А для варианта с отдельным потоком, никаких проблем не будет — просто подольше будет идти обработка, но без всяких зависаний приложения.
Обработка будет либо в главном потоке при без .ConfigureAwaite(false) либо в любом потоке из пула при .ConfigureAwaite(false)
я же написал.
Ну и если хочется оформи парсинг через Task и примени awaite
Шедулер сам решить где запускать или продолжить задачу
https://docs.microsoft.com/ru-ru/dotnet/api/system.threading.tasks.taskcreationoptions?view=netcore-3.1
_>Ты сейчас наверное скажешь, что правильный программист сразу же выделит парсинг в отдельный поток, как потенциально длительную операцию. Вот только тогда сразу появляется простейший вопрос: а зачем нам тогда нужен асинхронный ввод-вывод, если у нас и так создаётся поток под эту задачу?
Еще раз async awaite итак использует пул потоков. Незачем создавать еще свои потоки. При работе в сонтексте синхронизации
при .ConfigureAwaite(true) продолжение происходит в главном потоке для модификации контролов.
Уже все организовано. И незачем самому, изобретать велосипед!
Ты читал хоть
https://stackoverflow.com/questions/47741546/is-an-iocp-a-thread-that-is-running-while-the-i-o-is-taking-place-or-after
В .Net уже существуют настройки над IOCP
Не надо забывать и про кроссплатформенность. Да тот же Xamarin.Forms он кроссплатформенный.
И не надо изобретать велосипед там, где он уже создан
_>Здравствуйте, Serginio1, Вы писали:
S>>>>Вместо awaite File.ReadAllTextAsync нужно создавать бэкграунд поток, передавать в него метод в котором вызывать в итоге File.ReadAllText
_>>>Потому что для однопользовательского случая такая задача масштабируется гораздо лучше.
S>> И чем это лучше? Ты запускаешь отдельный поток. Который нихрена не делает, только ожидает когда данные считаются.
_>И в чём проблема с этим? ) Речь же не про тысячу таких потоков, а про один. )
Ты так и не ответил чем лучше?
S>>При этом морозит вспомогательный поток через объекты синхронизации до получения данных.
_>С чего бы это?
S>> При awaite File.ReadAllTextAsync данные передаются сразу в главный поток или если использовать .ConfigureAwaite(false) в любой поток.
S>> Чем это маштабируется то лучше?
_>Потому что помимо просто чтения файла в реальном мире у тебя будет ещё и какая-то его минимальная обработка. Например его парсинг. Если использовать твою схему с awaite File.ReadAllTextAsync, где по твоему будет происходить обработка? Если изначальный вызов был у тебя в UI потоке, то и обработка пойдёт там же. И это даже будет нормально работать у тебя на небольших файликах. А потом пользователь загрузит туда гигабайтный файл и всё твоё приложение зависнет на неопределённое время. А для варианта с отдельным потоком, никаких проблем не будет — просто подольше будет идти обработка, но без всяких зависаний приложения.
Обработка будет либо в главном потоке при без .ConfigureAwaite(false) либо в любом потоке из пула при .ConfigureAwaite(false)
я же написал.
Ну и если хочется оформи парсинг через Task и примени awaite
awaite Task.StartNew(()=>СинхронныйПарсинг(),
TaskCreationOptions.LongRunning | TaskCreationOptions.PreferFairness);Шедулер сам решить где запускать или продолжить задачу
https://docs.microsoft.com/ru-ru/dotnet/api/system.threading.tasks.taskcreationoptions?view=netcore-3.1
_>Ты сейчас наверное скажешь, что правильный программист сразу же выделит парсинг в отдельный поток, как потенциально длительную операцию. Вот только тогда сразу появляется простейший вопрос: а зачем нам тогда нужен асинхронный ввод-вывод, если у нас и так создаётся поток под эту задачу?
Еще раз async awaite итак использует пул потоков. Незачем создавать еще свои потоки. При работе в сонтексте синхронизации
при .ConfigureAwaite(true) продолжение происходит в главном потоке для модификации контролов.
Уже все организовано. И незачем самому, изобретать велосипед!
Ты читал хоть
https://stackoverflow.com/questions/47741546/is-an-iocp-a-thread-that-is-running-while-the-i-o-is-taking-place-or-after
В .Net уже существуют настройки над IOCP
Не надо забывать и про кроссплатформенность. Да тот же Xamarin.Forms он кроссплатформенный.
И не надо изобретать велосипед там, где он уже создан
Re[9]: Зачем нам асинхронность?
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
S>>>>Вместо awaite File.ReadAllTextAsync нужно создавать бэкграунд поток, передавать в него метод в котором вызывать в итоге File.ReadAllText
_>>>Потому что для однопользовательского случая такая задача масштабируется гораздо лучше.
S>> И чем это лучше? Ты запускаешь отдельный поток. Который нихрена не делает, только ожидает когда данные считаются.
_>И в чём проблема с этим? ) Речь же не про тысячу таких потоков, а про один. )
Ты так и не ответил чем лучше?
S>>При этом морозит вспомогательный поток через объекты синхронизации до получения данных.
_>С чего бы это?
S>> При awaite File.ReadAllTextAsync данные передаются сразу в главный поток или если использовать .ConfigureAwaite(false) в любой поток.
S>> Чем это маштабируется то лучше?
_>Потому что помимо просто чтения файла в реальном мире у тебя будет ещё и какая-то его минимальная обработка. Например его парсинг. Если использовать твою схему с awaite File.ReadAllTextAsync, где по твоему будет происходить обработка? Если изначальный вызов был у тебя в UI потоке, то и обработка пойдёт там же. И это даже будет нормально работать у тебя на небольших файликах. А потом пользователь загрузит туда гигабайтный файл и всё твоё приложение зависнет на неопределённое время. А для варианта с отдельным потоком, никаких проблем не будет — просто подольше будет идти обработка, но без всяких зависаний приложения.
Обработка будет либо в главном потоке при без .ConfigureAwaite(false) либо в любом потоке из пула при .ConfigureAwaite(false)
я же написал.
Ну и если хочется оформи парсинг через Task и примени awaite
Шедулер сам решить где запускать или продолжить задачу
https://docs.microsoft.com/ru-ru/dotnet/api/system.threading.tasks.taskcreationoptions?view=netcore-3.1
_>Ты сейчас наверное скажешь, что правильный программист сразу же выделит парсинг в отдельный поток, как потенциально длительную операцию. Вот только тогда сразу появляется простейший вопрос: а зачем нам тогда нужен асинхронный ввод-вывод, если у нас и так создаётся поток под эту задачу?
Еще раз async awaite итак использует пул потоков. Незачем создавать еще свои потоки. При работе в сонтексте синхронизации
при .ConfigureAwaite(true) продолжение происходит в главном потоке для модификации контролов.
Уже все организовано. И незачем самому, изобретать велосипед!
Ты читал хоть
https://stackoverflow.com/questions/47741546/is-an-iocp-a-thread-that-is-running-while-the-i-o-is-taking-place-or-after
В .Net уже существуют настройки над IOCP
Не надо забывать и про кроссплатформенность. Да тот же Xamarin.Forms он кроссплатформенный.
И не надо изобретать велосипед там, где он уже создан
_>Здравствуйте, Serginio1, Вы писали:
S>>>>Вместо awaite File.ReadAllTextAsync нужно создавать бэкграунд поток, передавать в него метод в котором вызывать в итоге File.ReadAllText
_>>>Потому что для однопользовательского случая такая задача масштабируется гораздо лучше.
S>> И чем это лучше? Ты запускаешь отдельный поток. Который нихрена не делает, только ожидает когда данные считаются.
_>И в чём проблема с этим? ) Речь же не про тысячу таких потоков, а про один. )
Ты так и не ответил чем лучше?
S>>При этом морозит вспомогательный поток через объекты синхронизации до получения данных.
_>С чего бы это?
S>> При awaite File.ReadAllTextAsync данные передаются сразу в главный поток или если использовать .ConfigureAwaite(false) в любой поток.
S>> Чем это маштабируется то лучше?
_>Потому что помимо просто чтения файла в реальном мире у тебя будет ещё и какая-то его минимальная обработка. Например его парсинг. Если использовать твою схему с awaite File.ReadAllTextAsync, где по твоему будет происходить обработка? Если изначальный вызов был у тебя в UI потоке, то и обработка пойдёт там же. И это даже будет нормально работать у тебя на небольших файликах. А потом пользователь загрузит туда гигабайтный файл и всё твоё приложение зависнет на неопределённое время. А для варианта с отдельным потоком, никаких проблем не будет — просто подольше будет идти обработка, но без всяких зависаний приложения.
Обработка будет либо в главном потоке при без .ConfigureAwaite(false) либо в любом потоке из пула при .ConfigureAwaite(false)
я же написал.
Ну и если хочется оформи парсинг через Task и примени awaite
awaite Task.Factory.StartNew(()=>СинхронныйПарсинг(),
TaskCreationOptions.LongRunning | TaskCreationOptions.PreferFairness);Шедулер сам решить где запускать или продолжить задачу
https://docs.microsoft.com/ru-ru/dotnet/api/system.threading.tasks.taskcreationoptions?view=netcore-3.1
_>Ты сейчас наверное скажешь, что правильный программист сразу же выделит парсинг в отдельный поток, как потенциально длительную операцию. Вот только тогда сразу появляется простейший вопрос: а зачем нам тогда нужен асинхронный ввод-вывод, если у нас и так создаётся поток под эту задачу?
Еще раз async awaite итак использует пул потоков. Незачем создавать еще свои потоки. При работе в сонтексте синхронизации
при .ConfigureAwaite(true) продолжение происходит в главном потоке для модификации контролов.
Уже все организовано. И незачем самому, изобретать велосипед!
Ты читал хоть
https://stackoverflow.com/questions/47741546/is-an-iocp-a-thread-that-is-running-while-the-i-o-is-taking-place-or-after
В .Net уже существуют настройки над IOCP
Не надо забывать и про кроссплатформенность. Да тот же Xamarin.Forms он кроссплатформенный.
И не надо изобретать велосипед там, где он уже создан