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

[zodiac]

Ну я комментил весь if, результат тот же:) Ладно, может попозже посмотрю или завтра. А если я код дам, то не лень будет посмотреть?

[BRE]

Ну я комментил весь if, результат тот же:) Ладно, может попозже посмотрю или завтра. А если я код дам, то не лень будет посмотреть?

Если сам не разберешься, выкладывай. Чем смогу - помогу.

[zodiac]

Не разобрался
Пишет:

Код:

QThread::wait: Thread tried to wait on itself

Вот код: http://92.63.106.179/svn/jabber/src/jProtocol.cpp
Функции:

Код:

void jProtocol::setStatus(Presence::PresenceType presence, QString message)
void jProtocol::run()
void jProtocol::onDisconnect(ConnectionError e)

[BRE]

Не разобрался
Пишет:

Код:

QThread::wait: Thread tried to wait on itself

Вот код: http://92.63.106.179/svn/jabber/src/jProtocol.cpp
Функции:

Код:

void jProtocol::setStatus(Presence::PresenceType presence, QString message)
void jProtocol::run()
void jProtocol::onDisconnect(ConnectionError e)

А как вызывается onDisconnect?
P.S. Посмотри код QThread::wait(), думаю вопрос отпадет.

[ритт]

по идее, всё правильно...
попробуй закомментировать всё тело onDisconnect, кроме выхода; и всё тело setStatus, кроме запуска.

как я понял, jClient->disconnect() зовёт jProtocol::onDisconnect(ConnectionError e) ?

[BRE]

Нужно уезжать, поэтому кратко.
Ты вызываешь wait в контексте останавливаемой нити, а нужно из контекста другой (например главной) нити.

[zodiac]

А как вызывается onDisconnect?
P.S. Посмотри код QThread::wait(), думаю вопрос отпадет.

Вызывается глуксом.
В смысле посмотреть?

по идее, всё правильно...
попробуй закомментировать всё тело onDisconnect, кроме выхода; и всё тело setStatus, кроме запуска.

как я понял, jClient->disconnect() зовёт jProtocol::onDisconnect(ConnectionError e) ?

Должен звать, да. так как "exit" выводится во всех случаях.

Нужно уезжать, поэтому кратко.
Ты вызываешь wait в контексте останавливаемой нити, а нужно из контекста другой (например главной) нити.

Ок, попробую через слот/сигнал сделать.
Т.е. из главной нити звать wait(), а exit() можно из самой?

[zodiac]

Вынес. Только щас когда идет подключение, то поток не завершается. Зато в остальных случаях завершается.

Хотел сделать так:

Код:

	if (!m_jabber_protocol->wait(1000))
		m_jabber_protocol->terminate();

Но ругается:

Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt. You must
reimplement QApplication::notify() and catch all exceptions there.

[BRE]

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

Только щас когда идет подключение, то поток не завершается.

Не совсем понял?

[zodiac]

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

Не совсем понял?

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

[BRE]

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

Я бы на твоем месте повтыкал побольше qDebug() << "....", буквально после каждого логического действия.
Типа:

Код:

void jProtocol::onDisconnect(ConnectionError e)
{
	qDebug() << "exit";
	TreeModelItem item;
	item.m_protocol_name = "Jabber";
	item.m_account_name = m_account_name;
	item.m_item_type = 2;

	qDebug() << "check error";					// <<<<<<<<<<<<<<<<<<<<<<
	if(e != ConnUserDisconnected && e != ConnNotConnected)
	{
		QString error_tr;
		switch(e)
		{
		...
		default:
			error_tr = tr("Unknown error. It is amazing that you see it... O_o");
			break;
		}
		qDebug() << "emit systemNotification";			// <<<<<<<<<<<<<<<<<<<<<<<<<
		emit systemNotification(m_account_name,error_tr);
	}//zodiac.test@jabber.egghost.ru

	qDebug() << "setAcountInOnlene()";				// <<<<<<<<<<<<<<<<<<<<<<<
	m_jabber_account->getPluginSystem().setAccountIsOnline(item, false);

	qDebug() << "setOffline()";						// <<<<<<<<<<<<<<<<<<<<<<<
	m_jabber_roster->setOffline();

	// <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< и т.д.
	emit setRealStatus(Presence::Unavailable);
	exit();
	wait();
}

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

[zodiac]

Я щас сделал так:

Код:

	emit setRealStatus(Presence::Unavailable);
	qDebug() << "exit2";
	emit threadWait();

И в jAccount.cpp:

Код:

void jAccount::threadWait()
{
	qDebug() << "threadWait()";
	m_jabber_protocol->exit();
	if (!m_jabber_protocol->wait(1000))
		m_jabber_protocol->terminate();
}

Вся фигня с wait(). Может как-нибудь с тобой можно по IM связаться? А то так на форуме долго:-)

[ритт]

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

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

[zodiac]

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

Ну так выбрано потому, что каждое подключение делает while (пока_не_ошибка_от_сервера) и в этом цикле все принимается. Так что не получится 1 поток для общения с сервером или предлагаешь делать поток и уже из него запускать все остальные потоки? %) Хм...

[ритт]

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

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