Qt4 и pthreads — как будут уживаться вместе?

AFAIK, в документации было упомянуто, что делать этого (крайне) не рекомендуется. Хотя возможно, что сейчас ситуация изменилась...

Вообще то Qt-шные треды их и используют. В документации обычно описывается thread safety, etc. Приятная неожиданность для меня была - thread safe COW строки.

> COW

Первый раз вижу такое сокращение. Обычно так и пишу "copy-on-write" или "с копированием при записи".

Щас посмотрел доки по Qt4 -- про X11-системы сказано, что используется libpthread для многопоточности. Про винду (да, приходится и с ней работать :-( ) не сказано ничего: "Please contact Trolltech Technical Support if you have queries". Но я устанавливал на Win GNU-реализацию pthread -- там нужно было ставить какой-то драйвер. А Qt достаточно просто скопировать куда нужно (ну, ещё плюс MinGW) -- и всё заработает. Вот мне и непонятно, у кого "более Ъ" реализация pthread: у троллей, или у GNU?

http://en.wikipedia.org/wiki/Copy-on-write

Copy-on-write (sometimes referred to as "COW") is an optimization strategy used in computer programming.

Под вендой свои потоки (CreateThread, etc), естественно они и используются. pthread под вендой это, наверное, для линуксовых программ, которые не хочется портировать.

Ну, про CreateThread и _beginthread, _beginthreadex я знаю, :-) просто счас хочу разорить свою контору на закупку Qt-шных коммерческих лицензий (иначе деньга может уйти Borland-у!), вот и смотрю, как-бы покроссплатформеннее сделать уже имеющееся, да чтобы с минимальными переделками.

почему бы собственно им не уживаться вместе, с учётом того, что для POSIX окружения сама Qt [естественно] базируется на pthread?

// wbr

Под виндой хэндлы окон и элементов управления можно использовать _только_ в том потоке, в котором они были созданы. Поэтому если речь идёт о действиях типа вызова Label::setText() параллельно из разных потоков, то это должно быть в общем случае (в целях переносимости) запрещено и в Qt, и в любом другом тулките. "Запрещено" - то есть оговорено в документации, что если будете так делать - получите непредсказуемые ошибки во время исполнения.

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

Откуда такие дровишки?

> Под виндой хэндлы окон и элементов управления можно использовать _только_ в том потоке, в котором они были созданы

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

Про одновременный доступ к ресурсу (хендл, или пофиг что) из разных потоков -- это синхронизировать нужно. Без взаимосинхронизации действительно будут странные эффекты. :-)

За точную формулировку сути проблемы не отвечаю. Общее правило по работе с widget'ами - "изменять только в одном потоке", я выловил из рассылки gtk+, документации по Java (Swing/SWT), и документации к Qt.

Вот, собственно, непосредственно по теме, выдержка из документации Qt4.
http://doc.trolltech.com/4.4-snapshot/threads.html
Раздел "QObject reentrancy":

"Although QObject is reentrant, the GUI classes, notably QWidget and all its subclasses, are not reentrant. They can only be used from the main thread. As noted earlier, QCoreApplication::exec() must also be called from that thread."

То есть в сокращённом переводе: "GUI-классы, включая QWidget и производные от него, могут использоваться _только_ из главного потока.

Повторять всю google-сессию по поиску фактов не буду. В общих чертах, это должно быть связано с тем, что в Win32 у каждого потока отдельная очередь сообщений, в которую пишутся сообщения для хэндлов, созданных в этом потоке, и из других потоков до этих сообщений никак не добраться. Отсюда проблемы при построении gui-тулкитов, из-за которых разработчикам проще запретить использование gui-элементов из всех потоков, отличных от главного с message-loop'ом.