Сообщение Re[5]: Зачем нам асинхронность? от 05.08.2020 20:47
Изменено 05.08.2020 20:49 AlexGin
Re[5]: Зачем нам асинхронность?
Здравствуйте, Mystic Artifact, Вы писали:
MA>Здравствуйте, AlexGin, Вы писали:
AG>>Мы можем сделать отдельный (рабочий) поток и в этом окне. И как-правило делаем его.
MA> Не в обиду, но окно имеет весьма специфическую связь с потоком.
Поток (рабочий поток исполнения) — естественно напрямую с окном не связан
В OS с графическим интерфейсом пользователя — все окна — это GUI-шный интерфейсный поток.
Рабочий поток — это несколько иное. Это именно сущность для рассчётов или длительных операций.
MA>С точки разгребания сообщений — тут скорее поток владеет окном. ADD: Я в не обиду, имел ввиду, что вы с колесиком наперегонки начали перлы выдавать в подветке.
Где мои перлы!?
Допускаю, что не расписывал мысли очень подробно.
Из-за чего — допускаю некорректное понимание изложенного мною выше.
Но никаких перлов — вроде здесь не излагал.
MA>Я еле понял что ты имел ввиду. Глаз ухватился за первое предложение и не захотел понимать дальше.
AG>>Можно также и "прокачивать_сообщения" OS — чтобы не было "замораживания" элементов GUI
MA>Безусловно. Более того в некотором смысле многие так и работают миксируя несколько очередей сообщений в одном цикле сообщений (нестандартном). Но практической сути это не меняет. Проблема только неоптимальности.
На сегодняшний день — правильнее применять многопоточность, нежели прокачку сообщений.
AG>>P.S. Локального сохранения (в файл) это не касается, если файл не совсем гигантского размера, а вот для работы с далеким серваком — это будет в тему.
MA> На самом деле это касается исключительно любого IO. Достаточно вставить в системник битый хард и часто можно будет наблюдать что некоторые приложения крайне жестко залипают, в то время как, тот же какой-нибудь злополучный хром — спокойно грузится как не бывало и браузит интернет, и его не волнует, что диск без буквы неожиданно притупил половину приложений. (Понятно, что как повезет, но думаю, идея понятна).
Есть принцып KISS.
Переусложнять архитектуру приложения, конечно можно, однако — не нужно.
Считать, что диск будет тупить, и из-за этого случая (вероятного на 0.1%) городить монстра —
всё-таки не следует.
А вот вариант, что твоё оптоволокно зацепил ковш экскаватора, учесть всё-же можно бы
(хотя и это — часто не учитывают и приложение ведет себя неадекватно при потере connect-а).
MA>Здравствуйте, AlexGin, Вы писали:
AG>>Мы можем сделать отдельный (рабочий) поток и в этом окне. И как-правило делаем его.
MA> Не в обиду, но окно имеет весьма специфическую связь с потоком.
Поток (рабочий поток исполнения) — естественно напрямую с окном не связан
В OS с графическим интерфейсом пользователя — все окна — это GUI-шный интерфейсный поток.
Рабочий поток — это несколько иное. Это именно сущность для рассчётов или длительных операций.
MA>С точки разгребания сообщений — тут скорее поток владеет окном. ADD: Я в не обиду, имел ввиду, что вы с колесиком наперегонки начали перлы выдавать в подветке.
Где мои перлы!?
Допускаю, что не расписывал мысли очень подробно.
Из-за чего — допускаю некорректное понимание изложенного мною выше.
Но никаких перлов — вроде здесь не излагал.
MA>Я еле понял что ты имел ввиду. Глаз ухватился за первое предложение и не захотел понимать дальше.
AG>>Можно также и "прокачивать_сообщения" OS — чтобы не было "замораживания" элементов GUI
MA>Безусловно. Более того в некотором смысле многие так и работают миксируя несколько очередей сообщений в одном цикле сообщений (нестандартном). Но практической сути это не меняет. Проблема только неоптимальности.
На сегодняшний день — правильнее применять многопоточность, нежели прокачку сообщений.
AG>>P.S. Локального сохранения (в файл) это не касается, если файл не совсем гигантского размера, а вот для работы с далеким серваком — это будет в тему.
MA> На самом деле это касается исключительно любого IO. Достаточно вставить в системник битый хард и часто можно будет наблюдать что некоторые приложения крайне жестко залипают, в то время как, тот же какой-нибудь злополучный хром — спокойно грузится как не бывало и браузит интернет, и его не волнует, что диск без буквы неожиданно притупил половину приложений. (Понятно, что как повезет, но думаю, идея понятна).
Есть принцып KISS.
Переусложнять архитектуру приложения, конечно можно, однако — не нужно.
Считать, что диск будет тупить, и из-за этого случая (вероятного на 0.1%) городить монстра —
всё-таки не следует.
А вот вариант, что твоё оптоволокно зацепил ковш экскаватора, учесть всё-же можно бы
(хотя и это — часто не учитывают и приложение ведет себя неадекватно при потере connect-а).
Re[5]: Зачем нам асинхронность?
Здравствуйте, Mystic Artifact, Вы писали:
MA>Здравствуйте, AlexGin, Вы писали:
AG>>Мы можем сделать отдельный (рабочий) поток и в этом окне. И как-правило делаем его.
MA> Не в обиду, но окно имеет весьма специфическую связь с потоком.
Поток (рабочий поток исполнения) — естественно напрямую с окном не связан
В OS с графическим интерфейсом пользователя — все окна — это GUI-шный интерфейсный поток.
Рабочий поток — это несколько иное. Это именно сущность для рассчётов или длительных операций.
MA>С точки разгребания сообщений — тут скорее поток владеет окном. ADD: Я в не обиду, имел ввиду, что вы с колесиком наперегонки начали перлы выдавать в подветке.
Где мои перлы!?
Допускаю, что не расписывал мысли очень подробно.
Из-за чего — допускаю некорректное понимание изложенного мною выше.
Но никаких перлов — вроде здесь не излагал.
MA>Я еле понял что ты имел ввиду. Глаз ухватился за первое предложение и не захотел понимать дальше.
AG>>Можно также и "прокачивать_сообщения" OS — чтобы не было "замораживания" элементов GUI
MA>Безусловно. Более того в некотором смысле многие так и работают миксируя несколько очередей сообщений в одном цикле сообщений (нестандартном). Но практической сути это не меняет. Проблема только неоптимальности.
На сегодняшний день — правильнее применять многопоточность, нежели прокачку сообщений.
AG>P.S. Локального сохранения (в файл) это не касается, если файл не совсем гигантского размера, а вот для работы с далеким серваком — это будет в тему.
MA> На самом деле это касается исключительно любого IO. Достаточно вставить в системник битый хард и часто можно будет наблюдать что некоторые приложения крайне жестко залипают, в то время как, тот же какой-нибудь злополучный хром — спокойно грузится как не бывало и браузит интернет, и его не волнует, что диск без буквы неожиданно притупил половину приложений. (Понятно, что как повезет, но думаю, идея понятна).
Есть принцып KISS.
Переусложнять архитектуру приложения, конечно можно, однако — не нужно.
Считать, что диск будет тупить, и из-за этого случая (вероятного на 0.1%) городить монстра —
всё-таки не следует.
А вот вариант, что твоё оптоволокно зацепил ковш экскаватора, учесть всё-же можно бы
(хотя и это — часто не учитывают и приложение ведет себя неадекватно при потере connect-а).
MA>Здравствуйте, AlexGin, Вы писали:
AG>>Мы можем сделать отдельный (рабочий) поток и в этом окне. И как-правило делаем его.
MA> Не в обиду, но окно имеет весьма специфическую связь с потоком.
Поток (рабочий поток исполнения) — естественно напрямую с окном не связан
В OS с графическим интерфейсом пользователя — все окна — это GUI-шный интерфейсный поток.
Рабочий поток — это несколько иное. Это именно сущность для рассчётов или длительных операций.
MA>С точки разгребания сообщений — тут скорее поток владеет окном. ADD: Я в не обиду, имел ввиду, что вы с колесиком наперегонки начали перлы выдавать в подветке.
Где мои перлы!?
Допускаю, что не расписывал мысли очень подробно.
Из-за чего — допускаю некорректное понимание изложенного мною выше.
Но никаких перлов — вроде здесь не излагал.
MA>Я еле понял что ты имел ввиду. Глаз ухватился за первое предложение и не захотел понимать дальше.
AG>>Можно также и "прокачивать_сообщения" OS — чтобы не было "замораживания" элементов GUI
MA>Безусловно. Более того в некотором смысле многие так и работают миксируя несколько очередей сообщений в одном цикле сообщений (нестандартном). Но практической сути это не меняет. Проблема только неоптимальности.
На сегодняшний день — правильнее применять многопоточность, нежели прокачку сообщений.
AG>P.S. Локального сохранения (в файл) это не касается, если файл не совсем гигантского размера, а вот для работы с далеким серваком — это будет в тему.
MA> На самом деле это касается исключительно любого IO. Достаточно вставить в системник битый хард и часто можно будет наблюдать что некоторые приложения крайне жестко залипают, в то время как, тот же какой-нибудь злополучный хром — спокойно грузится как не бывало и браузит интернет, и его не волнует, что диск без буквы неожиданно притупил половину приложений. (Понятно, что как повезет, но думаю, идея понятна).
Есть принцып KISS.
Переусложнять архитектуру приложения, конечно можно, однако — не нужно.
Считать, что диск будет тупить, и из-за этого случая (вероятного на 0.1%) городить монстра —
всё-таки не следует.
А вот вариант, что твоё оптоволокно зацепил ковш экскаватора, учесть всё-же можно бы
(хотя и это — часто не учитывают и приложение ведет себя неадекватно при потере connect-а).