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

>А так и должно быть. У кого поддержка лучше, тот и рулит.

Так проблема в том, что они возьмут мои наработки (у меня там несколько достаточно интересных know-how), не давая мне ничего взамен. Вообще говоря, это нечестно - тогда мне и смысла нет открывать компанию.

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

>> Я нашёл по ссылке функции для работы с сокетами. А виндовс, насколько помню, имеет статус POSIX-совместимой, так что я имею право пользоваться посиксными функциями и надеяться, что они сработают.

> "POSIX compatibility" в Win32 то-же для галки. на том куцем подмножестве POSIX API, который есть в RTL, что-то сложнее hello world написать весьма проблематично.

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

То есть мы пришли к выводу, что posix в win32 - это отписка. Собственно, о чём я на предыдущей странице и говорил, когда жалел разработчиков кроссплатформенного IPC.

> ты наверное имел ввиду "completion ports"? - Реализовано это крайне х**во, проще добавить в прогу новый поток (работать, кстати, тоже быстрее будет).

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

> Так проблема в том, что они возьмут мои наработки (у меня там несколько достаточно интересных know-how), не давая мне ничего взамен. Вообще говоря, это нечестно - тогда мне и смысла нет открывать компанию.

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

Друг, ты слишком заморочился. Фраза в FAQ, о которой ты говоришь, несколько оторвана от реальности и предназначена непонятно какой целевой аудитории (детям?). Попробуй смоделировать ситуацию, как Trolltech сможет засудить меня, начавшего разработку с OpenSource лицензией, а потом собравшим релиз с помощью коммерческой версии Qt. Откуда они, собственно, знают при каких обстоятельствах я разрабатывал этот софт? Может я использовал лишь тетрадку и ручку, а может - Evaluation-версию Qt. Прибавь к этому то, что ты живешь в России и твоя паранойя должна тебя немного отпустить.

> io ( http://www.iolanguage.com ) мне нравится больше. язык, в котором вообще отсутствуют ключевые слова

а return тогда что? функция?

>А уж сколько глюков можно огрести в логике из-за обилия функций с >похожей функциональностью в библиотеке... Одни таймеры чего стоят! А с таймерами что не так ?

>ты наверное имел ввиду "completion ports"? - Реализовано это крайне >х**во, проще добавить в прогу новый поток (работать, кстати, тоже >быстрее будет).

А где можно почитать про х**вость асинхронного ввода/вывода в Win32 ?

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

> А с таймерами что не так ?

Их наличие. Фактически это попытка засовать функциональность многопоточной программы в однопоточную. Отсюда всякие непонятки с синхронизацией и т.д.

Да, в UNIX-ах есть alarm(), да вот только он не так удобен к _неправильному_ применению как виндовые таймеры, потому чаще всего используется по назначению.

> вообще-то, AFAIU BSD layer был натянут на нативный WSA API. для тех, кому очень хочется.

Что вовсе не отменяет факта заимствования оного в додревние времена и с особым цинизмом, благо "самая свободная лицензия" позволяла.

>Их наличие. Фактически это попытка засовать функциональность >многопоточной программы в однопоточную. Отсюда всякие непонятки с >синхронизацией и т.д.

Можно все-таки конкретный пример который приводит к непоняткам ? А то как-то все абстрактно получается :-) Кстати , если эти таймеры так идеологически вредны , то можно их просто не использовать . А кому-то другому они возможно и пригодятся . Кстати , Вы о каких конкретно таймерах говорите (их там несколько) ? WaitableTimer ?

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

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

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

Не подходит. GUI достаточно у нас достаточно богатый (и уж точно виндовых пользователей нельзя пугать Tk :) ).

Да и "просто продавать" как разный софт тоже нельзя - если они не будут общаться по некоторым "стандартным" протоколам.

Зачем тогда было врать про поддержку?

>Друг, ты слишком заморочился. Фраза в FAQ, о которой ты говоришь, несколько оторвана от реальности и предназначена непонятно какой целевой аудитории (детям?). Попробуй смоделировать ситуацию, как Trolltech сможет засудить меня, начавшего разработку с OpenSource лицензией, а потом собравшим релиз с помощью коммерческой версии Qt.

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

Qt - говно, MFC - наше фсе!

>> Их наличие. Фактически это попытка засовать функциональность многопоточной программы в однопоточную. Отсюда всякие непонятки с синхронизацией и т.д.

> Можно все-таки конкретный пример который приводит к непоняткам ? А то как-то все абстрактно получается :-)

Потому что и вред абстрактен... Это примерно из той же серии, что и отсутствие синхронизации между потоками, имеющими общую память., то есть модет стукнуть, а может и нет.

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

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

> Кстати , если эти таймеры так идеологически вредны , то можно их просто не использовать.

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

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

> А кому-то другому они возможно и пригодятся . Кстати , Вы о каких конкретно таймерах говорите (их там несколько) ? WaitableTimer ?

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

>anonymous (*) (09.10.2007 17:16:33)

Я общался исключительно по почте, также предлагали купить лицензию за бешеное бабло, но когда я сказал, что у меня начинающая компания, и информация о скидках есть на сайте и что я столь дорогую лицензию никогда не куплю по причине отсутствия денег итд мне сразу сделали скидку в 65%. Естественно, они хотят заработать денег, а ты купить что хочешь с максимальной скидкой. Обычный бизнес.

А оно микроядерное ? Жду QT File System, QCP/IP и OpenQL

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

Нечитабельная хрень у кого получается ? Правильно , у того кто хрень написал :-) У меня был непродолжительный опыт общения с дельфи и как мне показалось сама среда способствуют небрежному написанию программ типа пихания всего и вся в OnClickXXX. Но это как говорится IMHO и зависит от разработчика :-)

Что касается функции "не помню какая (уж не SetTimer ли)" то я так и не понял зачем Вы ее использовали если она там была "не пришей ......" и источником всех бед ? Win32 достаточно богат функционалом , но это не значит что любая функция подходит для чего угодно .

> У меня был непродолжительный опыт общения с дельфи и как мне показалось сама среда способствуют небрежному написанию программ типа пихания всего и вся в OnClickXXX.

Да.

> Win32 достаточно богат функционалом , но это не значит что любая функция подходит для чего угодно .

Да.

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

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

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

3. Использование более лёгкого по написанию, но менее простого по логике и в отладке кода. Это как раз про использование таймеров.

4. "не значит что любая функция подходит для чего угодно" => есть риск использовать немного не ту функцию.

5. много страниц описания этого множества функций => ни у кого нет времени в этом досконально разобраться.

Зато при этом можно легко написать программу уровня "hello, world" :)

>То есть мы пришли к выводу, что posix в win32 - это отписка. Собственно, о чём я на предыдущей странице и говорил, когда жалел разработчиков кроссплатформенного IPC.

Открой для себя cygwin/msys и не морочь голову.

>> То есть мы пришли к выводу, что posix в win32 - это отписка. Собственно, о чём я на предыдущей странице и говорил, когда жалел разработчиков кроссплатформенного IPC.

> Открой для себя cygwin/msys и не морочь голову.

А цигвин в винде из коробки?

И второе: он всё равно является такой же обёрткой к вызовам WinAPI, как и упомянутый qt-шный IPC. То есть эффективность несколько ниже, чем могла бы быть.

> А мне всего-то по-хелловорлдовски надо писать единообразно в сокет и файл, не более.

ReadFile/WriteFile полностью покроют указанную задачу, ни больше ни меньше.

> То есть мы пришли к выводу, что posix в win32 - это отписка. Собственно, о чём я на предыдущей странице и говорил, когда жалел разработчиков кроссплатформенного IPC.

ну то, что POSIX в WinNT - это отписка, должен знать [и знает] любой минимально квалифицированный разработчик, и это ни для кого никогда не было секретом.

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

// wbr

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

> Да и "просто продавать" как разный софт тоже нельзя - если они не будут общаться по некоторым "стандартным" протоколам.

Протокол можно описать и приложить описание к гую. Всё равно вряд ли там будет что-то уж очень секретное. Но в то же вермя важно написать протокол так, чтобы он был удобен только в Вашей программе :)

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

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

// wbr

>Во-первых, это не разрешено _коммерческой_ лицензией на QT (у них в FAQ такой вопрос был). >Во-вторых, мы производим коробочный продукт, так что этот вариант не подходит.

Если не секрет, все-же, на какой библиотеки остановились? Доводы против QT у вас более чем разумные, imho.

>> А мне всего-то по-хелловорлдовски надо писать единообразно в сокет и файл, не более.

> ReadFile/WriteFile полностью покроют указанную задачу, ни больше ни меньше.

Да. Но с потерей кроссплатформенности этого фрагмента кода. Считайте, что количество test cases увеличится вдвое.

>> То есть мы пришли к выводу, что posix в win32 - это отписка. Собственно, о чём я на предыдущей странице и говорил, когда жалел разработчиков кроссплатформенного IPC.

> ну то, что POSIX в WinNT - это отписка, должен знать [и знает] любой минимально квалифицированный разработчик, и это ни для кого никогда не было секретом.

Со мной пытались спорить по этому поводу, так что не лишним было это упомянуть.

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

Подскажите кроссплатформенные киты на C.

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

> можно взглянуть хотя бы на коротенький список функций с похожей функциональностью из Win32 API. можно и по таймерам уж коли вы их вспомнили.

Многопоточность через таймеры и _нормальная_ многопоточность.

> А оно микроядерное ? Жду QT File System, QCP/IP и OpenQL

Тогда уж лучше сразу ждать наноядерное QNIX.

> ***Многопоточность через таймеры*** и _нормальная_ многопоточность.

В какой воспалённом мозге это (***) может быть во времена win32? Я думал это сдохло вместе с win 3.1.

>> ***Многопоточность через таймеры*** и _нормальная_ многопоточность.

> В какой воспалённом мозге это (***) может быть во времена win32? Я думал это сдохло вместе с win 3.1.

А программисты под win3.1 умерщвили свои навыки вместе с ней? Или тогда резко перестали рождаться быдлокодеры? ;)

> Их наличие. Фактически это попытка засовать функциональность многопоточной программы в однопоточную. Отсюда всякие непонятки с синхронизацией и т.д.

не понял, что конкретно вам не нравится и что конкретно значит "засовывать многопоточную программу в однопоточную"?

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

по поводу таймаутов, самый тривиальный вариант для потока:

--- cut ---
Platform SDK: DLLs, Processes, and Threads

The SleepEx function suspends the current thread until the specified condition is met. Execution resumes whens one of the following occurs:

An I/O completion callback function is called
An asynchronous procedure call (APC) is queued to the thread.
The minimum time-out interval elapses

DWORD SleepEx(
DWORD dwMilliseconds,
BOOL bAlertable
);

Parameters
dwMilliseconds
[in] Minimum time interval for which execution is to be suspended, in milliseconds.
A value of zero causes the thread to relinquish the remainder of its time slice to any other thread of equal priority that is ready to run. If there are no other threads of equal priority ready to run, the function returns immediately, and the thread continues execution.

A value of INFINITE indicates that the suspension should not time out.

bAlertable
[in] If this parameter is FALSE, the function does not return until the time-out period has elapsed. If an I/O completion callback occurs, the function does not return and the I/O completion function is not executed. If an APC is queued to the thread, the function does not return and the APC function is not executed.
If the parameter is TRUE and the thread that called this function is the same thread that called the extended I/O function ( ReadFileEx or WriteFileEx), the function returns when either the time-out period has elapsed or when an I/O completion callback function occurs. If an I/O completion callback occurs, the I/O completion function is called. If an APC is queued to the thread ( QueueUserAPC), the function returns when either the timer-out period has elapsed or when the APC function is called.
--- cut ---

man nanosleep - найдите 10 отличий.

> Да, в UNIX-ах есть alarm(), да вот только он не так удобен к _неправильному_ применению как виндовые таймеры, потому чаще всего используется по назначению.

в Win32 нет сигналов и, как следствие, alarm(2) - и слава тебе, Господи! что у разработчиков ядра NT хватило ума не вводить их в систему.

// wbr

Нормальная многопоточность в винде делается значительно проще, чем через таймеры. Обосновать?

> А программисты под win3.1 умерщвили свои навыки вместе с ней?

Ну не знаю, когда я ещё писал, то как-то перепрыгнул через win3.1 из резидентных программ под dos сразу на win32 и кастрированный win32s для этой самой 3.1. Просто период, когда это (***) было для меня еще, а потом стало уже не актуально практически нулевой.

> Нормальная многопоточность в винде делается значительно проще, чем через таймеры. Обосновать?

В win3.x нормальной не было, а про win32 обоснования не требуется.

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

Это из программы рисования фрактала Мандельброта.

while x<=xmax do
begin
y:=ymin;
while y<=ymax do
begin
xx:=x;
yy:=y;
for j:=1 to maxit+1 do
[...]
y:=y+dy;
end;
x:=x+dx;
application.ProcessMessages;
if stopf then
begin
stopf:=false;
save.enabled:=false;
saveimage1.Enabled:=false;
goto fin;
end;
end;

Мы видим здесь использование ProcessMessages для того, чтобы гуй отвечал на действия пользователя. stopf - флаг который устанавливается при нажатии кнопки "стоп".

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

PS. kalafuda, а что будет, если я уйду спать и не смогу ответить на очередной Ваш вопрос на время? Не хочу Вас разочаровывать ;)

> Нормальная многопоточность в винде делается значительно проще, чем через таймеры. Обосновать?

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

> Многопоточность через таймеры и _нормальная_ многопоточность.

не понял, поясните. что вы *конкретно* имеете ввиду под
1. многопоточностью через таймеры
2. нормальной многопоточностью

пример того и другого в студию.

// wbr

> по поводу таймаутов, самый тривиальный вариант для потока: <skipped />

Ну да, а я что-то говорил про таймауты?

> в Win32 нет сигналов и, как следствие, alarm(2) - и слава тебе, Господи! что у разработчиков ядра NT хватило ума не вводить их в систему.

А то бы вкупе с winapi сигналы были бы просто убийственны.

> Да. Но с потерей кроссплатформенности этого фрагмента кода. Считайте, что количество test cases увеличится вдвое.

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

> Подскажите кроссплатформенные киты на C.

никогда не задавался таким вопросом. на C++ связка ACE+Qt прекрасно себя зарекомендовала.

> Например, если время исполнения критично, то всякие врапперы и кроссплатформенные киты только затормозят програму.

при хорошо спроектированном окружении *и* его грамотном использовании это в 99% случаев неправда. a'la аргумент из разряда "виртуальные фунации работают медленнее..".

> Правда, можно делать под каждую платформу свою версию критичный участков, но это опять же лишний код.

не нужно.

// wbr

>> Многопоточность через таймеры и _нормальная_ многопоточность.

> не понял, поясните. что вы *конкретно* имеете ввиду под

> 1. многопоточностью через таймеры

Постоянный вызов какой-то функции через определённые промежутки.

> 2. нормальной многопоточностью

Два(или больше) потока и синхронизация.

> пример того и другого в студию.

Сложновато придумать подходящую задачу, особенно не завязанную на гуе... но я попробую:

длительная фоновая операция и отображение прогресса на гуе

1) фоновая операция разбивается на мелкие куски и вызывается по таймеру, чтобы не тормозить гуй

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

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

очень жаль. потому, что пример не имеет никакого отношения ни к Win32 API, ни к WinNT ни к Linux/POSIX ни к многопоточности вообще. максимум - к конкретной реализации цикла обработки сообщения в RTL Delphy ни больше ни меньше.

можно попросить другой пример, ближе к теме, в котором бы раскрывалась [или не раскрывалась] тема проблематики Win32 API?

> Мы видим здесь использование ProcessMessages для того, чтобы гуй отвечал на действия пользователя. stopf - флаг который устанавливается при нажатии кнопки "стоп". Я думаю, что грамотные программисты, присутствующие здесь, сами знают, как это сделать в два потока, чтобы было правильно и красиво.

грамотные программисты знают. и поэтому недоумевают, к чему был приведён этот пример.

> PS. kalafuda, а что будет, если я уйду спать и не смогу ответить на очередной Ваш вопрос на время? Не хочу Вас разочаровывать ;)

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

// wbr

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

Да. Но лично мне posix удобнее. А наткнуться на каку, которая называется посиксом в win32 было неприятно.

>> Подскажите кроссплатформенные киты на C.

> никогда не задавался таким вопросом. на C++ связка ACE+Qt прекрасно себя зарекомендовала.

Вот и я не знаю. Хотя таким наверно можно считать cygwin.

>> Например, если время исполнения критично, то всякие врапперы и кроссплатформенные киты только затормозят програму.

> при хорошо спроектированном окружении *и* его грамотном использовании это в 99% случаев неправда. a'la аргумент из разряда "виртуальные фунации работают медленнее..".

Не спорю. Но тонкие моменты всё равно иногда возникают.

>> Правда, можно делать под каждую платформу свою версию критичный участков, но это опять же лишний код.

> не нужно.

Если производительность _очень_ важна, то придётся. Или же вообще отказаться от кроссплатформенности и на полную использовать все фичи конкретной платформы. Но это уже тонкости.

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

вообще то, к многопоточности в её обыденном понимании что в мире POSIX что в Win32 это не имеет никакого отношения..

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

это уже ближе к жизни.

теперь внимание, вопрос: откуда взялось ваше утверждение, что Win32 API заставляет идти по первому пути? что-то кроме приведённого примера с дельфи.

// wbr

> Да. Но лично мне posix удобнее. А наткнуться на каку, которая называется посиксом в win32 было неприятно.

"удобнее" - термин субъективный и явно не строгий. хотя как лично мнение вполне имеет право на существование.

> Вот и я не знаю. Хотя таким наверно можно считать cygwin.

боже упаси от ицыгвина...

// wbr

> очень жаль. потому, что пример не имеет никакого отношения ни к Win32 API, ни к WinNT ни к Linux/POSIX ни к многопоточности вообще. максимум - к конкретной реализации цикла обработки сообщения в RTL Delphy ни больше ни меньше.

> можно попросить другой пример, ближе к теме, в котором бы раскрывалась [или не раскрывалась] тема проблематики Win32 API?

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

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

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

> А то бы вкупе с winapi сигналы были бы просто убийственны.

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

// wbr

> теперь внимание, вопрос: откуда взялось ваше утверждение, что Win32 API заставляет идти по первому пути? что-то кроме приведённого примера с дельфи.

Я не сказал, что _заставляет_. Win32 API предоставляет 2 пути: через таймеры и через потоки. Так как первый путь _кажется_ более простым, то его используют. И за счёт этого получают запутанный алгоритм.

Да, профессиональный программист так не сделает. Но мы же не ждём от всех программистов профессионализма.

>> А то бы вкупе с winapi сигналы были бы просто убийственны.

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

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