План развития Qt

> Под апач будет mod_c++ или mod_qt так? ;)

вообще-то webkit -- это со стороны клиента, но если вы сделаете "mod_c++ или mod_qt" -- я с удовольствием на это посмотрю ;)

> Но Microsoft хотя бы не просит СТОЛЬКО денег за базовые инструменты разработки.

вообще-то БАЗОВЫЙ инструмент здесь -- это gcc & Co, и они бестплатны

> Почему же, тут всё раскрыто: виден костыль(ProcessMessages), оставшийся от однопоточного программирования в win3.1(как мне тут уже рассказали), который никто не помешал использовать.

я правильно понимаю, что исходя из примера, в котором горе-разработчик по всей видимости не владея навыками разработки ПО в многопоточной среде начал использовать привычный и видимо единственно известный ему механизм "распараллеливания" исполнения задачи вы делаете вывод, что Win32 API порочно во всем, что касается многопоточности? пусть даже оставим в стороне мелкие придирки a'la "я не увидел в приимере ни одной ф-и из Win32 API".

> Программисты - они как физические объекты - идут по пути наименьшего сопротивления. Потому такие перлы со смертью win3.1 не закончились.

вообще то, мне казалось, что мы обсуждаем достоинства и недостатки того или иного API. конкретно - Win32 и POSIX. а отнюдь не программистов.

> ЗЫ. слово "Delphi" пишется немного не так, как Вы изволили написать.

да, вполне возможно, я отнюдь не претендую на корректность написания.

// wbr

> собственно, какойто фреймворк замутить хотят под это дело После того, как прочел это, желание посещать ЛОР пропало. Ладно в комментариях идиотизм был всегда, так он уже и в новостях. Причем все чаще.

> Читать учимся: "of up to three Qt licenses". У меня пять разработчиков (ну и еще я шестой). > Я разговаривал с маркетингом у Trolltech - они предлагали максимум 10% скидку, что совсем несерьезно.

А Вы делайте, как большинство нормальных людей под линуксом, 2 варианта -- один под GPL, другой -- коммерческий. т.е. 3 человека используют Qt под GPL, 3 коммерческую -- экономия на 50% :)

А чисто коммерческой частью будет только 1, то вообще впишитесь в минимум.

>Почему же, тут всё раскрыто: виден костыль(ProcessMessages), оставшийся от однопоточного программирования в win3.1(как мне тут уже рассказали), который никто не помешал использовать.

Дело в том, что главный цикл обработки сообщений в дельфях скрыт от разработчика. Если бы он был виден, то в мозгу при написании кода щёлкнуло бы понимание некрасивости такого решения. Других причин, кроме незнания внутреннего устройства Win-программы, у такого решения нет, и не надо приплетать Win3.1.

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

>> Почему же, тут всё раскрыто: виден костыль(ProcessMessages), оставшийся от однопоточного программирования в win3.1(как мне тут уже рассказали), который никто не помешал использовать.

> я правильно понимаю, что исходя из примера, в котором горе-разработчик

Это был я семилетней давности :)

> по всей видимости не владея навыками разработки ПО в многопоточной среде начал использовать привычный и видимо единственно известный ему механизм "распараллеливания" исполнения задачи вы делаете вывод, что Win32 API порочно во всем, что касается многопоточности?

Нет, я не делал таких выводов. Я просто показал, что _обилие_ функций может вести к менее хорошему коду. "Краткость - сестра таланта"(имеется в виду не краткость кода, а лаконичность мысли, если применять пословицу к софту).

> пусть даже оставим в стороне мелкие придирки a'la "я не увидел в приимере ни одной ф-и из Win32 API".

Ну если копнуть глубже, то мы увидим, что ProcessMessages ссылается на какую-нибудь функцию из winapi. И подозреваю, что она примерно так и называется.

>> Программисты - они как физические объекты - идут по пути наименьшего сопротивления. Потому такие перлы со смертью win3.1 не закончились.

> вообще то, мне казалось, что мы обсуждаем достоинства и недостатки того или иного API. конкретно - Win32 и POSIX. а отнюдь не программистов.

Я не говорю, что то или иное API плохое, я не настолько хорошо разбираюсь в обоих. Но, как мне кажется, сама winapi порождает трудноотлаживаемые программы.

>> Почему же, тут всё раскрыто: виден костыль(ProcessMessages), оставшийся от однопоточного программирования в win3.1(как мне тут уже рассказали), который никто не помешал использовать.

> Дело в том, что главный цикл обработки сообщений в дельфях скрыт от разработчика. Если бы он был виден, то в мозгу при написании кода щёлкнуло бы понимание некрасивости такого решения. Других причин, кроме незнания внутреннего устройства Win-программы, у такого решения нет, и не надо приплетать Win3.1.

ну так вроде бы Вы и сказали про то, что такой приём применялся в win3.1 из-за отсутствия альтернативы?

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

Его и в qt сделать нельзя. На гуй там вфделяется только один тред.

> Ну если копнуть глубже, то мы увидим, что ProcessMessages ссылается на какую-нибудь функцию из winapi. И подозреваю, что она примерно так и называется.

как мне уже показали, тут я ошибся.

Что-то мы немного о разных вещах стали говорить. Попробую пояснить свою точку зрения; она основывается на следующих утверждениях: 1. Ты пишешь коробочный продукт => его публичная жизнь начинается с некой версии 1.0. 2. Любой разработчик вправе сменить лицензию GPL своего продукта на какую угодно другую, если ему принадлежат авторские права на 100% кода, причем в ЛЮБОЙ момент разработки 3. Лицензия троллей не обязывает тебя синхронизировать код продукта с каким-нибудь публичным SVN-сервером сразу же после того, как ты измененил один символ в своих исходниках 4. Любой разработчик вправе самостоятельно решать в какой момент времени делать свой open-source (GPL) продукт доступным сообществу (альфа-версия, RC или сразу final - не важно). "Релизь рано, релизь часто" - это всего лишь девиз. 5. Тролли врядли могут заставить кого-либо сделать публичными исходники его программы "поскорее", если эту программу еще в глаза толком никто не видел (в соответствии с пунктом 1).

Теперь объясни, ЧТО КОНКРЕТНО И РЕАЛЬНО мешает тебе сменить лицензирование ДО релиза? Ну кроме FAQ, пожалуйста... В худшем случае (это если ты закоренелый неудачник) вопрос о лицензировании будет решен в досудебном порядке (ты просто купишь лицензию и все). Если бы бизнес был бы такой кристально чистой и честной вещью какой он тебе представляется, им бы занимался только Всевышний, а в мире не существовало бы ни одного ларька, не говоря уже о любителях поделок от микрософта.

P.S. Странно слышать о нехватке 10000 USD на лицензии при таком "корпоративном" и "серьезном" подходе к разработке. У вас хоть один серверок какой-нибудь есть? Из дома принес?

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

кстати, а можете привести пример библиотеки с многопоточным гуём?

>> как показывает пример POSIX, они убийственны и без привлечения Win32 API, вполне достаточно ввести в среду потоки.

> Теперь я позволю себе попросить примера у Вас. Не откажете мне в такой слабости?

ну почему же, конечно не откажу.

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

в многопоточном же окружении для того, чтобы оповестить о каком то событии заблокированный на системном вызове поток приходится или устраивать пляски с бубном вокруг pthread_kill() что непосредственно и зачастую весьма нетривиально влияет на всю архитектуру системы, или оборачивать все обращения к системным вызовам в select() + socketpair() что то-же не добавляет простоты + жрёт ресурсы (fd * 2) и не всегда возможно, или select() + таймауты, что негативно сказывается на времени отклика системы при больших таймаутах и жручести ресурсов при маленьких и то-же не всегда возможно.

если суммарно - механизмы синхронизации потоков в POSIX by design совершенно отвязаны от исторически сложившегося API системных вызовов. они параллельны друг-другу и друг с другом попросту не работают. нельзя, к примеру, сказать select() на fd и на условную переменную и таким образом через pthread_cond_broadcast() разбудив все интересующие нас потоки. без бубна того или иного калибра тут не обойтись.

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

ps: select() можно заменить на poll()/epoll()/you name - суть от этого не меняется.

// wbr

> кстати, а можете привести пример библиотеки с многопоточным гуём?

вы будете смеяться, но таки сам Win32

// wbr

>> Ну если копнуть глубже, то мы увидим, что ProcessMessages ссылается на какую-нибудь функцию из winapi. И подозреваю, что она примерно так и называется.

> как мне уже показали, тут я ошибся.

Ничуть. ProcessMessages вызывает такой winapi код в делфи:

MSG msg;
while(PeekMessage(&msg,0,0,0,PM_REMOVE))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}

>ps: select() можно заменить на poll()/epoll()/you name - суть от этого не меняется

Я юзал pselect для этих целей. Он может просыпаться от сигнала и сообщать об этом. Всё равно криво, но не так погано, как без pselect :)

> Я юзал pselect для этих целей. Он может просыпаться от сигнала и сообщать об этом. Всё равно криво, но не так погано, как без pselect :)

pselect - это по сути то-же самое. после начинают появляться искусственные административные потоки "для обработки и диспетчеризации сигналов", миллионные вызовы в gettimeofday() для обновления таймаута на *select, и так далее и тому подобное. и в реальном 24x7 сервисе получаем весьма нетривиальную конечную пирамиду возведённую лишь для того, чтобы вся эта херня реально работала и не лочилась. куда испаряется та простота? пустой звук..

// wbr

>> кстати, а можете привести пример библиотеки с многопоточным гуём? >вы будете смеяться, но таки сам Win32

Не понимаю ваш тут флейм на эту тему. Функции ReadFile/WriteFile единообразно работают с файлами, сокетами, МайлСлотами, анонимными и именованными каналами и пр. Только названия функций другие нежели в POSIX. По поводу ГУЯ - он по определению везде асинхронно-однопоточный. Есть исключение в виде программ от МС которые открывают несколько главных фреймов, при этом сохраняя один процесс (IE6, возможно оффис). При этом на каждый фрейм заводится отдельный тред со своей очередью сообщений. Данная архитектура упрощает взаимодействие между разными фреймами, т.к память общая. По этой же причине все фреймы IE6 умирают одновременно.

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

Осмыслил пока не полностью, так что от комментариев временно воздержусь.

Но возник вопрос: это ведь всегда можно сделать без pthreads, так что проблема в том, что не стоит совать потоки туда, куда не надо. Так?

Кстати, у потоков есть ещё один минус: один засегфолтившийся поток рушит весь процесс, так что отдельные процессы окажутся даже надёжнее. Другое дело. что там обмен будет не так быстр...

> Они б еще о GPL 3 подумали. Aaron J. Seigo said: "The GPLv3 question did indeed come up; no new info yet, just that it is being worked on (we already knew that ;)"

>> кстати, а можете привести пример библиотеки с многопоточным гуём?

> вы будете смеяться, но таки сам Win32

В принципе да, там своя очередь сообщений для каждого окна... Так и иксы вроде эвенты по окнам, а не по процессам рассылают?

> Не понимаю ваш тут флейм на эту тему. Функции ReadFile/WriteFile единообразно работают с файлами, сокетами, МайлСлотами, анонимными и именованными каналами и пр. Только названия функций другие нежели в POSIX.

Не только названия, но и способы вызова. Фактически для кроссплатформенного приложения придётся писать два варианта: для unix и для win32.

Кстати, тут ещё один флейм есть: про слишком большое количество функций в winapi, переросший в проблемы многопоточности.

>вообще-то БАЗОВЫЙ инструмент здесь -- это gcc & Co, и они бестплатны

Да ну? У MS в базовом инструментарии еще и офигительная библиотека классов и визуальный редактор с неплохой визуальной библиотекой (WinForms).

>А Вы делайте, как большинство нормальных людей под линуксом, 2 варианта -- один под GPL, другой -- коммерческий. т.е. 3 человека используют Qt под GPL, 3 коммерческую -- экономия на 50% :)

Нам GPL противопоказан, так что не получится.

> Но возник вопрос: это ведь всегда можно сделать без pthreads, так что проблема в том, что не стоит совать потоки туда, куда не надо. Так?

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

> Кстати, у потоков есть ещё один минус: один засегфолтившийся поток рушит весь процесс, так что отдельные процессы окажутся даже надёжнее.

надёжнее с точки зрения OS - да. проще в реализации -> надежнее by design - совсем не факт. скорее, сложный протокол обмена между дочерними процессами может внести кучу проблем и наоборот ослабить надёжность ПО. впрочем, это уже зависит от реализации.

> Другое дело. что там обмен будет не так быстр...

мягко говоря. операция взятия мьютекса pthread_mutex_lock() по скорости несравнима с IPC между процессами.

// wbr

> Не только названия, но и способы вызова. Фактически для кроссплатформенного приложения придётся писать два варианта: для unix и для win32.

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

> Кстати, тут ещё один флейм есть: про слишком большое количество функций в winapi, переросший в проблемы многопоточности.

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

// wbr

>Теперь объясни, ЧТО КОНКРЕТНО И РЕАЛЬНО мешает тебе сменить лицензирование ДО релиза? Ну кроме FAQ, пожалуйста... В худшем случае (это если ты закоренелый неудачник) вопрос о лицензировании будет решен в досудебном порядке (ты просто купишь лицензию и все). Если бы бизнес был бы такой кристально чистой и честной вещью какой он тебе представляется, им бы занимался только Всевышний, а в мире не существовало бы ни одного ларька, не говоря уже о любителях поделок от микрософта.

Мы вообще ведем весь бизнес полностью кристально честно (чем очень удивили налоговую :) ), у нас куплены все лицензии. Так как иначе аудиторы съедят - BSA уже наведывалась (компания в США зарегистрирована, с филиалом в Украине).

Конкретно для GPL мешает то, что часть нашего продукта имеет уникальные решения (в том числе и специальные алгоритмы), которых нет у конкурентов. Они только сейчас аннонсировали поддержку аналогичных нашим фич - видимо зареверсили-таки нас.

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

>P.S. Странно слышать о нехватке 10000 USD на лицензии при таком "корпоративном" и "серьезном" подходе к разработке. У вас хоть один серверок какой-нибудь есть? Из дома принес?

Для разработки - локально стоит обычный Core 2 Duo с Линуксом, вполне хватает.

Сайт/репозиторий/почта/DNS/... - на выделенном сервере, который мы арендуем за $200 в месяц в хостинговом центре в Нью-Йорке.

> Я в норвежском не силён, но в переводе книги Бланшета и Саммерфилда именно Эттрич. А если верить разговорникам, то звук от этого слога либо "ш", либо "к".

Демо-трек в amaroK всех рассудит :)

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

>> Не только названия, но и способы вызова. Фактически для кроссплатформенного приложения придётся писать два варианта: для unix и для win32.

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

в случае сферической программы в вакуме никакой фреймворк не спасёт :) но ACE посмотрю, раз так рекламируете.

>> Кстати, тут ещё один флейм есть: про слишком большое количество функций в winapi, переросший в проблемы многопоточности.

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

Да я не говорил, что проблемы многопоточности проистекают из большого количества функций. Это _тема разговора_ плавно перешла от одного вопроса к другому.

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

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

Действительно, по мере развития WinAPI в нём появились дублирующие функции, выполняющие одно и тоже, но с разными возможностями. Однако, каждый раз, как вводилась новая, улучшенная функция, её старая версия помечалась как deprecated, и в её описании прямо указывалось на нежелательность применения. Таким образом, когда программист читает описание функции WinExec, ему прямо говорится, что вместо неё надо использовать CreateProcess.

>У меня разработка идет с ведением всей документации, для аудита процесса разработки и безопасности. Так как мы работаем с healthcare-данными, да еще и наши клиенты под SOX попадают и наш продукт с ним должен быть совместим. А там достаточно сильный аудит требуется - поэтому у нас ВСЕ лицензионно-чистое.

Ну кто мешает Вам, как владельцу всех прав, вести разработку под GPL, а потом перелицензировать под EULA?

> По поводу ГУЯ - он по определению везде асинхронно-однопоточный. Есть исключение в виде программ от МС которые открывают несколько главных фреймов, при этом сохраняя один процесс (IE6, возможно оффис). При этом на каждый фрейм заводится отдельный тред со своей очередью сообщений. Данная архитектура упрощает взаимодействие между разными фреймами, т.к память общая. По этой же причине все фреймы IE6 умирают одновременно.

примерно так, правда слово frame я бы заменил на window. а под window может скрываться не только всем привычное окно..

--- cut ---
DLLs, Processes, and Threads Technical Articles
Multiple Threads in the User Interface

...........
How Multiple Threads Affect Window Management

A Windows NT-based application can have multiple threads of execution, and each thread can create windows by calling the CreateWindow function. An application must remove and process messages posted to the message queues of its threads. A single-threaded application uses a message loop in its WinMain function to remove and send messages to the appropriate window procedures for processing.

Changes to the Message Loop
Applications with multiple threads must include a message loop in each thread that creates a window. The message loop and window procedure for a window must be processed by the thread that created the window. If the message loop does not reside in the same thread that created the window, the DispatchMessage function will not get messages for the window. As a result, the window will appear but won't show activation and won't repaint, be moved, receive mouse messages, or generally work as you expect it to.
...........
--- cut ---

i.e. можно создать N потоков, в каждом из них создать по окну в том числе и дочернему и в контексте потока заниматься обработкой отображения чего-то там в этом окне. вполне даже многопоточный GUI.

// wbr

Возможно, я чего-то не знаю о специфике разработки софта в Украине (мне кажется, она ничем не отличается от нашей), но страх перед BSA при отсутствии проблем с налоговой - это полный бред. Ладно, в любом случае, я похоже тебя неправильно понял: если ваши бинари уже могут достать все кому не лень, в такой ситуации Trolltech вполне уже смог бы вам предъявить некоторые вопросы, если бы вы использовали Qt. Непонятно только к чему были заявления относительно невозможности использования свободной лицензии Qt на этапе предрелизной закрытой разработки.

> Ви таки случайно не оголтелый фанатик проприетарщины? А то LGPL что даётся на GTK+ (замечу, "+", а то какие-то совсем странные ассоциации возникают) не вызывает абсолютно никаких проблем, в отличие от.

Дубина. GPL на QT проблем с открытым софтом не вызывает никаких, а с проприетарщиной могут быть порблемы, для них - коммерческая QPL!

> Одинокому девелоперу надо будет потратить что-то около $3000 на лицензию. Да, и с каждым релизом лицензия на QT становится все дороже. Так что имеем тот же vendor lock-in, что и с Microsoft. Но Microsoft хотя бы не просит СТОЛЬКО денег за базовые инструменты разработки.

Что есть то есть - .нет раздают, msvs уже на шару раздают, привлекая к своей платформе "developers!developers!developers!" , а эти ... создают проблемы проприетарщикам. Да ну и плевать - пусть открывают код.

> Читать учимся: "of up to three Qt licenses". У меня пять разработчиков (ну и еще я шестой). > Я разговаривал с маркетингом у Trolltech - они предлагали максимум 10% скидку, что совсем несерьезно.

Можно три купить, откуда они знают, что у вас шесть разработчиков? Можно вообще одну, кто и как докажет, что это не один человек написал?

>Конкретно для GPL мешает то, что часть нашего продукта имеет уникальные решения (в том числе и специальные алгоритмы), которых нет у конкурентов. Они только сейчас аннонсировали поддержку аналогичных нашим фич - видимо зареверсили-таки нас.

Ты правда считаешь, что "зареверсить" твой быдлокод проще, чем написать его с нуля? Блин, даже микрософт так не считает, какой же крутой анонимус.

> Я в норвежском не силён, но в переводе книги Бланшета и Саммерфилда именно Эттрич. А если верить разговорникам, то звук от этого слога либо "ш", либо "к".

Эттрихь. Это немец.

> Он НЕМЕЦ!

Теперь полностью убедился, в амароке вступительная речь Матиаса Эттриха есть, где он точно произносит свою фамилию :)

> У MS в базовом инструментарии еще и офигительная библиотека классов

Это об MFC такие добрые слова? :)

> визуальный редактор с неплохой визуальной библиотекой (WinForms).

Glade

> в многопоточном же окружении для того, чтобы оповестить о каком то событии заблокированный на системном вызове поток приходится или устраивать пляски с бубном вокруг pthread_kill() что непосредственно и зачастую весьма нетривиально влияет на всю архитектуру системы

Какая-то сферическая проблема в вакууме. Можно подробнее - заблокированность на каком вызове? оповещение о каком событии?

> Какая-то сферическая проблема в вакууме. Можно подробнее - заблокированность на каком вызове? оповещение о каком событии?

объекты:
* основной поток
* дочерний поток
* событие (сигнал, таймаут, внешний запрос etc).

действия:
* основной поток: порождает N дочерних и ждет их завершения.
* дочерний поток: в цикле принимает соединение, считывает запрос, обрабатывает его и отсылает ответ.

простейший пример - http сервер с пулом рабочих потоков.

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

// wbr

> Можно три купить, откуда они знают, что у вас шесть разработчиков? Можно вообще одну, кто и как докажет, что это не один человек написал?

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

>Но рассмотрим, к чему ведёт большое количество функций, с помощью >которых можно сделать одинаковый функционал разными способами: >1. много кода в системной библиотеке. соответственно, сложнее >поддерживать и ловить баги. >2. есть несколько вариантов сделать одно и то же. Соответственно, >больше возможность сделать баг в прикладной программе, забыв вызвать >какую-то из промежуточных функций. >3. Использование более лёгкого по написанию, но менее простого по >логике и в отладке кода. Это как раз про использование таймеров. >4. "не значит что любая функция подходит для чего угодно" => есть риск >использовать немного не ту функцию. >5. много страниц описания этого множества функций => ни у кого нет >времени в этом досконально разобраться. >Зато при этом можно легко написать программу уровня "hello, world" :)

1.Не Вы же поддерживаете системную библиотеку , какая Вам разница ? Вас же не сильно расстаивает что libc и ядро unix(linux) тоже не маленькие ?

2.Я не понял как из первого предложения следует второе ? Если человек путает разные подходы к решению одной задачи , то это проблема опять же не разработчиков Win32.

3.Ну что с таймерами не так ? Что там сложного ? Приведите пример .

4.Риск не ознакомиться с документацией есть всегда :-)

5.Зачем сразу изучать все функции ? Вы решаете конкретную задачу , а не пишете энциклопелию .

>Сложновато придумать подходящую задачу, особенно не завязанную на >гуе... но я попробую: >длительная фоновая операция и отображение прогресса на гуе >1) фоновая операция разбивается на мелкие куски и вызывается по >таймеру, чтобы не тормозить гуй >2) фоновая операция пускается в отдельном потоке и вывешивает свой >прогресс в общую переменную. откуда её забирает гуй(хоть даже и по >таймеру, важно что таймер делает тривиальные операции)

Первый вариант применялся в win3.1 ибо многопоточности там не было . В win32 применять такой подход я думаю никто бы не догадался .

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

> * как по получению в основном потоке события прервать исполнение дочерних? в течении заданного времени (не больше).

красиво - никак не сделаешь. Но я не понимаю, зачем это нужно: основная нить не принимает соединения, и больше ничем не знимается, а приняв его, отдает в очередь, на которой ожидают рабочие нити. Рабочая нить обрабатывает запрос до конца, больше не общаясь с основной. Единственное, зачем здесь прерывать исполнение рабочей нити - это завершение работы, но для этого вполне подойдут и pthread_cancel, и pthread_kill. Ждать завершения потоков тоже нужно только в случае завершения всего приложения.

> * чуть более общий вариант: получение события в произвольном потоке, не только в основном.

не очень конкретное требование, тебе не кажется? событие, укладывающееся в pthread_cond_wait - легко.

> все идёт вполне нормально до тех пор, пока вопрос не заходит о том

надеюсь, в дальнейшей дискуссии тема раскроется более полно, но Ваши слова заставят меня впредь быть с pthreads более осторожным

>В принципе да, там своя очередь сообщений для каждого окна... Так и >иксы вроде эвенты по окнам, а не по процессам рассылают?

Небольшая поправочка . В Win32 очередь сообщений ассоциирована не с окном , а с потоком . Заводить на каждый HWND по очереди сообщений - это слишком жирно :-)

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

> Действительно, по мере развития WinAPI в нём появились дублирующие функции, выполняющие одно и тоже, но с разными возможностями. Однако, каждый раз, как вводилась новая, улучшенная функция, её старая версия помечалась как deprecated, и в её описании прямо указывалось на нежелательность применения. Таким образом, когда программист читает описание функции WinExec, ему прямо говорится, что вместо неё надо использовать CreateProcess.

Эта текучесть API в угоду удобству(зачастую, удобству написания _простых_ программ) не делает большой чести проектировщикам WinAPI. Ровно как и появляющиеся каждые 3 года новые версии .net framework, где приходится долго портировать продукт. Вот юниксным форкам более тридцати лет и никто их не депрекейтил :)

>> * как по получению в основном потоке события прервать исполнение дочерних? в течении заданного времени (не больше).

> красиво - никак не сделаешь.

красиво - да, скорее всего не сделать. по крайней мере

> Но я не понимаю, зачем это нужно: основная нить не принимает соединения, и больше ничем не знимается,

ну почему же ничего не делает? вполне даже делает.

штатный пример - основная нить занимается обработкой сигналов. в ней разрешены обработчики SIGINT/SIGTERM, в то время как в рабочих по понятным причинам запрещено все, кроме какого-то внутреннего служебного сигнала под pthread_kill() например SIGUSR1/2.

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

дальше встает тот самый вопрос: как оповестить набор дочерних потоков в момент времени X из родительского о каком-то событии. с учетом того, что один-несколько-все дочерние потоки могут в текущий момент времени находиться внутри системного вызова причем без таймаута so могут висеть там в общем случае непонятно сколько.

> а приняв его, отдает в очередь, на которой ожидают рабочие нити. Рабочая нить обрабатывает запрос до конца, больше не общаясь с основной.

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

после перебора немногочисленных вариантов по всей очевидности придем к стандартной схеме "родительский socketpair() + select() в дочернем потоке", что конечно в принципе работает, но
а) явно не является верхом изящества, нуждается в аккуратной реализации etc.
б) дюже охоче до ресурсов бо на каждый дочерний поток у нас уходит по два левых файловых дескриптора. если потоков у нас сотни/тысячи, то это уже ощутимая проблема.

> Единственное, зачем здесь прерывать исполнение рабочей нити - это завершение работы,

не единственное. может быть внешнее требование об обновлении какой-то конфигурации сервиса etc etc.

> но для этого вполне подойдут и pthread_cancel, и pthread_kill.

прекрасно. но чтобы послать pthread_kill() нам нужно как минимум:
а) слать его на каждый поток -> иметь список дочерних потоков -> иметь в конечном итоге менеджер потоков.
б) аккуратно расставлять маски сигналов на потоках.

то-же прямо скажем не так чтобы сильно просто а тем более элегантно.

> Ждать завершения потоков тоже нужно только в случае завершения всего приложения.

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

// wbr