Завершнение QThread

[zodiac]

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

Так как библиотека написана на C++, без QT.

упд:
> пока_не_ошибка_от_сервера
означает ли это, что такой цикл имеется в каждом потоке соединения с сервером? т.е. в аська-протоколе свой цикл, в жаббер-протоколе - свой и т.д.?

Я джаббере -- в каждом потоке такой цикл, а аське же нет. Аська писалась на C++/QT без всяких сторонних библиотек.

[ритт]

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

Так как библиотека написана на C++, без QT.

упд:
> пока_не_ошибка_от_сервера
означает ли это, что такой цикл имеется в каждом потоке соединения с сервером? т.е. в аська-протоколе свой цикл, в жаббер-протоколе - свой и т.д.?

Я джаббере -- в каждом потоке такой цикл, а аське же нет. Аська писалась на C++/QT без всяких сторонних библиотек.

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

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

                              /--- акк_icq_1
   г--- плагин icq --- +--- акк_icq_2
  |                     /|\  \--- акк_icq_3
  |                      |
  |                     \|/
гуй --- менеджер соединений
  |                         /|\
  |                          |
  |                         \|/   /--- акк_jabber_1
   L--- плагин jabber --- +--- акк_jabber_2
                                   \--- акк_jabber_3

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

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

[BRE]

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

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

[zodiac]

Аську вообще сюда не надо приплетать. Там никто ничего переписывать не будет уже :-)
В принципе щас можно разделить яббер на еще 1 поток и остальные потоки, которые будут запускаться из того (я правильно понял?), но это уже не сегодня.
Я не совсем понял как лучше сделать. Когда запускать этот поток? И как из него уже управлять другими.

[ритт]

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

[BRE]

> Задержки могут быть и в обработчиках сигналов...
между потоками? ну-ну

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

[zodiac]

если архитектура qutim позволяет, в настройках плагина можно дать пользователю возможность указать несколько аккаунтов или добавить/удалить. ))

Архитектура отдает все проблемы плагина -- плагину. Завтра днем посмотрю эту идею, если время хватит.

[naico]

А подскажите средство в духе kill, чтобы действовало решительно и беспощадно:)

[pastor]

А подскажите средство в духе kill, чтобы действовало решительно и беспощадно:)

void QThread::terminate ()   [slot]
Terminates the execution of the thread. The thread may or may not be terminated immediately, depending on the operating systems scheduling policies. Use QThread::wait() after terminate() for synchronous termination.
When the thread is terminated, all threads waiting for the thread to finish will be woken up.
Warning: This function is dangerous and its use is discouraged. The thread can be terminate at any point in its code path. Threads can be terminated while modifying data. There is no chance for the thread to cleanup after itself, unlock any held mutexes, etc. In short, use this function only if absolutely necessary.
Termination can be explicitly enabled or disabled by calling QThread::setTerminationEnabled(). Calling this function while termination is disabled results in the termination being deferred, until termination is re-enabled. See the documentation of QThread::setTerminationEnabled() for more information.

[naico]

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

[pastor]

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

[zodiac]

Разобрался с потоками. Большое спасибо BRE