Здравствуйте, уважаемый Mystic Artifact, Вы писали:

MA>Ну вот опять. Почему рабочий поток это сущность, да еще с этим высоким предназначением?

Никто о "высоком_предназначании" не говорит. Просто — некоторая полезная необходимость.

MA>Это вполне физическое явление во вполне конкретных процессорах. И почему для рассчетов и длительных операций?

А где ещё делать длительные операции? Насчёт расчётов — пока забудем, но делать длительные операции в GUI-потоке: просто ужасно.

MA>Нет же — лучше всего они умеют исполнять ноп или и вовсе спать. Что за загрузка задач наперед через определения? Вы как-то не правильно используете потоки, заставляя их волочь какие-то вычислительные задачи. К ним нужно же, с любовью и пониманием. Схватил, вывел из системы и спать навеки до резета. Хорошо — энергию не кушают. Заняты *тоже* полезным делом — энергию экономят.

В этом случае, разработчик может гордо сказать:
— Наш сервис/приложение мнгопоточно!
Правда, что за необходимость в этой много-поточности разработчик объяснить НЕ может

MA>Но создать поток из окна — это безусловно пёрл. Я вот с телефона не могу на десктопе порождать потоки, а ты?

Поток к окну непосредственного отношения НЕ ИМЕЕТ.
Создаётся он — из нашего приложения (или сервиса).
При этом, сигнал на создание потока — может генерироваться из любого места нашего проекта.
Также возможен вариант — создание потока при старте и ожидание им запроса (например — в очереди запросов) на полезную работу.

AG>На сегодняшний день — правильнее применять многопоточность, нежели прокачку сообщений.
MA>Это мягко говоря не так. Всегда можно найти ситуационно лучшие решения в плане реализации, но потребители как раз и занимаются забором новых сообщений и как правило в цикле.

Так как раз для того, чтобы не делать закат солнца прокачку сообщений вручную, и создаём новый поток (или используем какой-либо уже созданный ждущий поток).

MA>Более того, задачи не требующие многопоточности, что? очевидно, что не нуждаются в ней.

Мы здесь обсуждаем задачи, требующие парралелизма. И реализацию этого парралелизма.
Как один из вариантов реализации парралелизма — многопоточность (ИМХО наиболее популярный на сегодня).

MA>Это решение иногда на рантайме, чаще на программисте, но уж точно не на "на сегодняшний день повитуха задекларировала".

AG>>Есть принцып KISS.
MA> Это херня полная для хипстеров. Ни один реальный проект не целуется ни в куда.

https://medium.com/@devisha.singh/the-kiss-principle-in-software-development-everything-you-need-to-know-dd8ea6e46bcd

MA>Во-первых, у меня не оптоволокно, а витая пара. Во-вторых, она войну пережила.

Я написал это только для примера, что связь может быть не надежной.
Несмотря на то, что у меня оптоволокно и 4G-радиоканал, стараюсь учитывать возможность отсутствия коннекта при проектировании приложений.

Здравствуйте, уважаемый Mystic Artifact, Вы писали:

MA>Ну вот опять. Почему рабочий поток это сущность, да еще с этим высоким предназначением?

Никто о "высоком_предназначании" не говорит. Просто — некоторая полезная необходимость.

MA>Это вполне физическое явление во вполне конкретных процессорах. И почему для рассчетов и длительных операций?

А где ещё делать длительные операции? Насчёт расчётов — пока забудем, но делать длительные операции в GUI-потоке: просто ужасно.

MA>Нет же — лучше всего они умеют исполнять ноп или и вовсе спать. Что за загрузка задач наперед через определения? Вы как-то не правильно используете потоки, заставляя их волочь какие-то вычислительные задачи. К ним нужно же, с любовью и пониманием. Схватил, вывел из системы и спать навеки до резета. Хорошо — энергию не кушают. Заняты *тоже* полезным делом — энергию экономят.

В этом случае, разработчик может гордо сказать:
— Наш сервис/приложение мнгопоточно!
Правда, что за необходимость в этой много-поточности разработчик объяснить НЕ может

MA>Но создать поток из окна — это безусловно пёрл. Я вот с телефона не могу на десктопе порождать потоки, а ты?

Поток к окну непосредственного отношения НЕ ИМЕЕТ.
Создаётся он — из нашего приложения (или сервиса).
При этом, сигнал на создание потока — может генерироваться из любого места нашего проекта.
Также возможен вариант — создание потока при старте и ожидание им запроса (например — в очереди запросов) на полезную работу.

AG>На сегодняшний день — правильнее применять многопоточность, нежели прокачку сообщений.
MA>Это мягко говоря не так. Всегда можно найти ситуационно лучшие решения в плане реализации, но потребители как раз и занимаются забором новых сообщений и как правило в цикле.

Так как раз для того, чтобы не делать закат солнца прокачку сообщений вручную, и создаём новый поток (или используем какой-либо уже созданный ждущий поток).

MA>Более того, задачи не требующие многопоточности, что? очевидно, что не нуждаются в ней.

Мы здесь обсуждаем задачи, требующие парралелизма. И реализацию этого парралелизма.
Как один из вариантов реализации парралелизма — многопоточность (ИМХО наиболее популярный на сегодня).

MA>Это решение иногда на рантайме, чаще на программисте, но уж точно не на "на сегодняшний день повитуха задекларировала".

AG>Есть принцып KISS.
MA>Это херня полная для хипстеров. Ни один реальный проект не целуется ни в куда.

https://medium.com/@devisha.singh/the-kiss-principle-in-software-development-everything-you-need-to-know-dd8ea6e46bcd

MA>Во-первых, у меня не оптоволокно, а витая пара. Во-вторых, она войну пережила.

Я написал это только для примера, что связь может быть не надежной.
Несмотря на то, что у меня оптоволокно и 4G-радиоканал, стараюсь учитывать возможность отсутствия коннекта при проектировании приложений.