Можно ещё проще. Добавляем свой Device ID от GeForce карты в inf файл в драйвер Quadro. После этого устанавливаются драйвера от Quadro на GeForce.
Такой трюк позволяет поставить нужную мне программу nview (менеджер рабочих столов, как в Linux), которая входит в состав драйверов Quadro, в драйверах GeForce её нет (раньше была).
В столбец NONE значения заносятся «как есть» (этот тип используется по умолчанию, если не задан другой)
Поверил, но оказалось не совсем так, если 64-битное число хранить в таком поле, то оно портится (INTEGER тоже не подходит), приходится использовать поле TEXT.
Вероятно тип NONE преобразуется автоматически к TEXT или INTEGER, в зависимости от содержимого.
Ясно, я то считал под condition variable — это переменная, изменение которой защищено мьютесом. Обычно g_cond_signal()/g_cond_wait() используется в связке с какой-нибудь переменной, но её может и не быть.
GCond*, несправедливо обозванная вами «сигналом», это и есть condition variable.
Так как нет перевода для средства синхронизации, вот и придумал более менее близкое по действию.
Что конкретно вы считаете неправильным? В противном случае это просто ничем не обоснованная критика. Может я чего-то и не понимаю, но все примеры были проверены практически.
condition variables — дополнительное средство синхронизации, на случай пропуска сигнала перед началом ожидания. Из за того что condition variables не были рассмотрены в статье, не значит что там что-то написано неправильно.
Попытаюсь ответить на подобные вопросы: А почему не Кьют? Меня на самом деле волновал похожий вопрос но в более глобальном смысле, почему не C++? А я бы спросил — почему не boost?
Целью статьи не было сравнение способов написания многопоточных кросс-платформанных приложений. Я предложил один из вариантов, который использую сам.
Несомненно, в Qt есть свои средства, и глупо было бы в Qt-шное приложение встраивать Glib, для С++ возможно больше подойдёт boost, но есть люди, которые предпочитают писать на чистом Си, такие как я, вот для них в первую очередь и предназначена эта статья.
К GUI можно обращаться из нескольких потоков одновременно, достаточно обернуть код в gdk_threads_enter() / gdk_threads_leave(). Это позволяет избегать создания лишних функций для таймеров.
А разве не так происходит?
Вот описание из документации: Atomically releases mutex and waits until cond is signalled.
А condition variables можно и не использовать.
На практике происходит так: Если в одном и том же потоке заблокировать мьютекс через g_mutex_lock(), то повторные g_mutex_lock() в этом же потоке не приведут к блокировке. Другое дело, что потом придётся два раза разблокировать мьютекс. То есть вложенные мьютескы реально работают, но раз документация говорит, что это приводит к неопределённым результатам, видимо стоит избегать подобных ситуаций.
У меня Cambalache тоже не отображала центральное окно с виджетами, пока не отключил у webkit аппаратное ускорение
export WEBKIT_DISABLE_COMPOSITING_MODE=1Такой трюк позволяет поставить нужную мне программу nview (менеджер рабочих столов, как в Linux), которая входит в состав драйверов Quadro, в драйверах GeForce её нет (раньше была).
Вероятно тип NONE преобразуется автоматически к TEXT или INTEGER, в зависимости от содержимого.
Бинарники GTK+ для win64: ftp.acc.umu.se/pub/gnome/binaries/win64/gtk+
Так как нет перевода для средства синхронизации, вот и придумал более менее близкое по действию.
А почему не Кьют?
Меня на самом деле волновал похожий вопрос но в более глобальном смысле, почему не C++?
А я бы спросил — почему не boost?
Целью статьи не было сравнение способов написания многопоточных кросс-платформанных приложений. Я предложил один из вариантов, который использую сам.
Несомненно, в Qt есть свои средства, и глупо было бы в Qt-шное приложение встраивать Glib, для С++ возможно больше подойдёт boost, но есть люди, которые предпочитают писать на чистом Си, такие как я, вот для них в первую очередь и предназначена эта статья.
Вот описание из документации: Atomically releases mutex and waits until cond is signalled.
А condition variables можно и не использовать.