но есть несколько недостатков.....

1. все очень быстро напишется
2. подискутировать и порассусоливать будет не о чем дольше трех минут
3. портянки кода, вышеприведенные станут какими-то коротенькими

> Denchik   (19.08.17 00:09) [58]

Внимательно не смотрел, но смутила асинхронная посылка указателя
с последующим освобождением памяти (например,  строки 132, 133).

Безопасно можно слать <=8 байт (wparam, lparam).

--
Regards, LVT.

> rrrrrr ©   (19.08.17 09:44) [59]

> итого. универсальный случай для консоли и гуи.

Делать в консоли гуишные потоки не очень-то кошерно.

Да и, во-ще, если и делать нечто полезное, то начать надо с пула потоков, IMHO.

--
Regards, LVT.

> rrrrrr ©   (19.08.17 09:47) [60]

> 2. подискутировать и порассусоливать будет не о чем дольше
> трех минут

У мну есть 3 минуты, готов порассусоливать на такую тему:
диспетчер и рабочие потоки обмениваются данными через асинхронные сообщения, а решение о загрузке потоков диспетчер принимает
по статистике занятости потока  (GetThreadTimes?).

Конечно, было б интереснее держать рабочие потоки "горячими",
но пока в голову не  лезет как  его сделать.

--
Regards, LVT.

Делать в консоли гуишные потоки не очень-то кошерно.

во первых что такое гуишные потоки? во вторых где они у меня там?
в третьих с какого года и каким фз win32 консоли запрещено пользоваться гуи?

Конечно, было б интереснее держать рабочие потоки "горячими",
но пока в голову не  лезет как  его сделать.

так все же просто.
однажды давно я тянул формы 101 и 102 с цб коих было миллион.
и сначала потоки были одноразовыми.
потом я подумал а зачем это собственно?
в результате они перестали умирать выполнив порцию работы.

то есть стал сендмессадж с результатом наверх. и по результатам сенда поток либо получал новое задание, либо умирал когда дело подошло к концу.

сверху был диспетчер, который еще считал, дает ли увеличение количества потоков прирост производительности показателю "получено форм в секунду"

и адаптивно выбирал всю полосу прокси которая доступна рабочему месту.

дома где я один и оптика можно было иметь линейный рост производительности где-то до нескольких сотен потоков.

а на работе было все уже печальнее. 10-15 потоков и все.
дальнейший рост просто тратил ресурсы не увеличивая скорость обработки

> rrrrrr ©   (19.08.17 11:19) [64]

> во первых что такое гуишные потоки? во вторых где они у
> меня там?
IsGUIThread function. Вызов Post(Thread)Message делает их таковыми.

> в третьих с какого года и каким фз win32 консоли запрещено
> пользоваться гуи?
Никем не запрещено. Просто не люблю котлеты с мухами.

> то есть стал сендмессадж с результатом наверх. и по результатам
> сенда поток либо получал новое задание, либо умирал когда

У ТС речь идет о ловле блох (на фоне дисковых операций или, скажем,
скорости канала). Тут и SendMessage чемпион, но до всеобщей пользы,
IMHO, далековато.

--
Regards, LVT.

знаешь, все эти капризы конечно очень элегантны и гламурны.

но когда кто-то ждет от меня не кода, а результата от этого кода,
и когда я знаю, что ускорить получение резалта можно только выбрав весь канал,
то мне как-то пофик,
становится ли поток гуёвым от пост/сенд мессадж и прочие абстрактности вроде чемпионства синронного сенда.
тем более, что можно было догадаться что никакого приза за тормоза он там у меня не берет, так как диспетческий поток не обрабатывает полученные данные, а отдает их другому потоку.

мне как бы не до этого.
мне хорошо, когда на единицу времени уменьшается количество людей,
которые продолжают ждать от меня чего-то.

плюс три дня трендеть на тему плёвой задачки уровня школьного кружка погромирования - это как бы роскошь а не средство движения вперед.
тоже имхо конечно

> Denchik   (17.08.17 16:54) 

автор, тебе тут правильно несколько раз намекнули. все упирается в hdd/ssd.
даже два потока приведут к значительной деградации скорость, по сравнению с одним. почитай где-нибудь как hdd устроен. с SSD конечно легче, но не намного, ну 2-3 потока максимум, и то, тестировать надо.