Что может мешать RSocket.Close()

[veon1]

Есть 2 потока RThread с общей кучей(heap).
В первом создается объект с RSocket и инициализируется.
Второй запускается когда необходимо закрытие соединения и вызов RSocket.Close().
При доступности объекта(разделяемой куче) вызов RSocket.Close() вылетает с Exception 100, Kern-Exec 0

[A.A.M.]

При создании сессии к сокет-серверу (RSockServ) в первом потоке вы не забываете расшарить ее (после подключения RSockServ::Connect()) используя вызов RSockServ::ShareAuto() ?

[veon1]

Да, спасибо, я решил эту проблему. Именно ShareAuto помогло. Я отправлял ответ, но видимо форум не сработал.

Сейчас другая проблема - при попытке удалить CSecureConnection тот же Exception 0. TLS соединение открывается поверх этого же сокета. Но при обращении к нему из другого потока (CancellAll, Close ...) или уделение вызывает панику.

[JasFas0la]

А может стоит открыть 2 RSocketServ в обоих потоках?.. не думаю что это сильно повредит работе приложения.

[veon1]

Проблему RSocketServ победили, его надо просто зашарить.

Но тек архитектура предполагает использование потоков для рассылки сообщений. Одним из который является disconnect, который должен освободить память *CSecureConnection. Вот при его delete вылетает ошибка, хотя другие объекты которые создаются вместе с ним (буферы) удаляются спокойно.

ps. да я знаю что использовать RThread для системы сообщений неверное решение, но это кроссплатформенный код, большой и старый.

[truf]

Имеется в виду CSecureSocket, а не CSecureConnection?

[JasFas0la]

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

[veon1]

2truf:
да именно CSecureSocket, писал по памяти.

2JasFas0la:
Нельзя, на это нет достаточного количества ресурсов (людей времени и желания). Код, реализующий рассылку событий, отлажен и работает на Windows, WinMobile, Linux и Symbian. Пусть безобразно, но однообразно.

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

[truf]

Мое имхо. Насколько я понимаю ситуацию - CSecureSocket это практически интерфейс+резолвер, который ищет и подгружает полиморфную dll с реализацией протокола, переданного ему в качестве аргумента. Dll грузится в процесс и возвращает указатель на MSecureSocket, который помещается в члены CSecureSocket. В дальнейшем работа ведется через CSecureSocket с объектом, реализующим интерфейс MSecureSocket.
Я пробовал грузить реализацию SSL3.0 и прокидывать указатель MSecureSocket вместо CSecureSocket между потоками и получал KERN-EXEC 0 при вызове Close(). Так что, как мне кажется, проблемма в реализации протокола в этом плагине. Возможно, она создает сессии с какими либо серверами, которые не могут расшариваться. Возможно, использует TLS (thread local storage) для хранения глобальных данных. Если это так, то работать с одним объектом CSecureSocket загрузившим реализацию такого протокола из различных потоков невозможно. Исходников ssl.dll ни в уже открытом ядре Symbianь ни в BAK'е я не нашел, так что проверить не могу. Также маловероятно, что SSL.DLL предоставляет какое-либо дополнительное API помимо фабричной функции, возвращающей MSecureSocket.

В общем, в любом случае нужно просить совета старших товарищей в англоязычной части форума, либо даже обращаться на форум Symbian Foundation. Там есть люди, которые знают все.

[JasFas0la]

2truf: он точно создаёт сессии. И не всегда их закрывает при уничтожении. Это такой баг реализации.
2veon: я работал с этим классом в singleThread приложении. Проблем не обнаружилось.

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

void CThreadActive::Request()
{

SetActive();
iStatus = KRequestPending;
}

. вот собственно и всё из другого потока вызывается следующий код:

void CThreadActive::SendCmd( const CThreadCmd& aCmd )
{
iMutex.Wait();
m_lastCmd = aCmd;
iMutex.Signal();
if( iStatus.Int() == KRequestPending ) {
TRequestStatus* status = &iStatus;
m_thread.RequestComplete( status, KErrNone ); // m_thread - RThread() потока, в котором создан CThreadActive.
}
}

и мы получаем управление данным потоком. управлние попадает сюда:

void CThreadActive::RunL()
{
iMutex.Wait();
if( iStatus.Int() == KErrNone ) {
CImgThreadCmd _cmd = m_lastCmd;
iMutex.Signal();
Request();
TRAPD( err, HandleCmd( _cmd ) );
if( err != KErrNone ) {
User::Panic( _L("CIT::Error"), KErrGeneral );
}
}
else {
iMutex.Signal();
Request();
}
}

а в HandleCmd можно, например, обработать ECmdDestroySecureSocket.

[JasFas0la]

или можно сделать всё проще. Создать CPeriodic и стэк запросов в потоке. Тогда, когда нужно что-либо выполнить в потоке, помещаете необходимую комманду в стэк, запускаете таймер через iTimer->Start(...); и получаете управление в статическую функцию, переданную как параметр в функцию CPeriodic::Start, в которой и обрабатываете комманды в стэке. только нужно залогинить поток посредством m_thread.Logon(iStatus);

[truf]

Можно еще RThread::Rendezvous() использовать.

[veon1]

2JasFas0la
Приведенный пример коммуникации между потоками мягко говоря плох. Да я использовал такой метод с стеком и таймером, но отказался из-за нестабильности работы активного объекта - выпадала ошибка при активации таймера при большой нагрузке. Да и обрабатывать события по времени плохой шаг.

Более правильным вариантом является использование встроеных механизмов IPC - очереди сообщений (RMsgQueue) и нотификации о её наполнении.

Это все бы работало, есть 1 "но" - нет гарантии, даже наоборот, скорее всего вызвающий поток или будет завершен, или ему будет выделенно другая задача. А повиснуть на CActiveScheduler::Start мне не позволит логика приложения.

2truf. спасибо за полный квалифицированый ответ.