Асинхронный вызов RConnection::Start

[truf]

Я вот тоже вчера задумался, как RConnectionMonitor без ActiveScheduler'а умудряется асинхронный notification делать. И решил что либо он создает новый поток, и в нем ждет ответа сервера асинхронно или синхронно. Либо он проверяет CActiveScheduler::Current() на NULL, и если его нет создает и подключает планировщик втихаря.

Сейчас провел пару экспериментов в эмуляторе:
1. Предложенный мной способ работает.
2. Пробовал зависать на User::WaitForAnyRequest() - это метод ждет срабатывания дефолтного семафора потока, используемого активными объектами. И что бы вы думали? Его вышибает. Программа правда продолжает выполнение сразу за ним и никаких callback'ов не вызывается. Но это значит, что RConnectionMonitor использует асинхронные запросы, причем в том же, а не в новом потоке.
3. Потом я отключил создание CActiveScheduler'а, в надежде, что RConnectionMonitor втихаря создаст свой. И? Он вылетел с паникой E32USER-CBase 44 на NotifyEventL(). У него там, видимо, простой CActiveScheduler::Add(this).

Итого
1. вы меня обманули, планировщик активных объектов у вас в потоке есть. Иначе, у вас на monitor.NotifyEventL( iObserver ); поток бы вылетал.
2. Наш R-класс event'ы получает асинхронно. Поэтому, если у вас объект RConnectionMonitor в одном потоке с observer'ом, то вы вместо повисания на семафоре можете ставить CActiveScheduler::Start(). А в callback методе вместо отвисания - CActiveScheduler::Stop(). И после отработки callback метода программа продолжит выполнение после CActiveScheduler::Start(). Я проверил - работает. Вызывать Start() нужно только после NotifyEventL(), иначе поток зависнет. И если у вас есть в потоке еще какие нибудь скрытые\явные асинхронные запросы, то тормозить нужно не на CActiveScheduler, а на CActiveSchedulerWait, иначе все кроме RConnectionMonitor отвалится.

[veon1]

Спасибо, получилось да - обманул. Создавал RConnectionMonitor в конструкторе, из главного потока у которого установлен CActiveScheduler, а ждал его в другом потоке.

пришлось создавать все динамически

TInt CIoctlCommandsImpl::WaitForInterfaceListChanges(TInt nId)
{
CActiveScheduler *as = new(ELeave) CActiveScheduler;
CleanupStack::PushL(as);
CActiveScheduler::Install(as);
User::LeaveIfError(monitor.ConnectL());
TInt err = monitor.NotifyEventL( iObserver );
User::LeaveIfError(err);
CActiveScheduler::Start();
monitor.CancelNotifications();
monitor.Close();
CleanupStack::PopAndDestroy(as);
return KErrNone;
}

так нотификация срабатывает.
по-моему слегка накладно пересоздавать кучу объектов, но это Symbian Style =(.

[truf]

по-моему слегка накладно пересоздавать кучу объектов, но это Symbian Style =(.

Symbian style заключается в отказе от использования потоков.

Главная проблема многопоточности в том, что она сложна для разработчиков приложений.<...> Многопоточная система должна предоставлять программисту системные примитивы для обеспечения взаимодействия потоков. <...> Внезапно, разработчики столкнулись с необходимостью беспокоиться о вещах, которые раньше были само собой разумеющимися, таких как целостность и устойчивость контекста во время исполнения. Им пришлось заботиться об этом самим на уровне приложения. Хуже того, они вынуждены были учиться справляться с потенциально сложным взаимодействием потоков в рамках их программ<...>

Но, в то время как другие операционные системы всё больше и больше адаптируют многопоточность для использования на прикладном уровне, активные объекты Symbian OS предлагают альтернативную и более простую модель для управления асинхронным поведением приложения в событийно-ориентированной системе. Активные объекты показали себя настолько эффективными на практике, что на большинстве уровней над ядром, включая системные службы, они стали стандартным шаблоном для реализации любого асинхронного поведения.
В результате, при программировании для Symbian OS практически отпала необходимость в семафорах, блокировках и прочих примитивах потока. Это значительно упростило разработку, и снизило вероятность возникновения потенциальных ошибок.
Целевой рынок устройств для Symbian OS, по сути, является потребительским, и надежность — главный фактор на этом рынке. Поэтому, отсутствие ошибок при программировании – прямой путь к успеху. Есть еще одна важная причина создания активных объектов — это экономия процессорного времени и энергии. Symbian OS рассчитана на устройства, работающие от батарей, и обладающих процессорами с достаточно скромной производительностью. Операционные системы персональных компьютеров, даже после миграции на мобильные устройства, хуже приспособлены к работе с подобным аппаратным обеспечением.

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

Бен Моррис. CActive и все все все.

Так что проблема в том что вы портируете не родной код. А потом будете жаловаться что Symbian OS тормозит и глючит. Я лишь дважды сталкивался с оправданной необходимостью создания второго потока в процессе. Больше не доводилось.

[veon1]

EConnectionCreate отрабатывает раньше чем wifi конфигурируется

Оффтоп:

Но, в то время как другие операционные системы всё больше и больше адаптируют многопоточность для использования на прикладном уровне,

Symbian изобретает свой велосипед - активные объекты. Вместо того чтоб оптимизировать ядро и железо под параллелизм. OS должна не позволять пользователским приложениям её "тормозить и глючить". Ко всему прочему, обязана поддерживать хотя какие-то стандарты.

От меня же ничего не зависит - я выполняю заказ. Нужно чтоб часть кода которая уже есть и успешно работает и поддерживается на win nt, win ce, linux работала на S60 c минимальными различиями. Переписать заново + трекать, отображать изменения мне никто не позволит.

[truf]

Symbian OS не изобретает, а изобрела этот велосипед 10-15 лет назад. Еще для _того_ железа. Увеличение мощности железа, это не только рост стоимости продукта, но и расход аккумулятора. Как тянут железо за ПО мы видим на примере Winodws, но на смартфонах такой финт не пройдет - есть пределы.
Пользовательским процессам Symbian себя тормозить не позволяет. Паника и есть легализованное убийство процесса, и применяется она по малейшему поводу. А если вам удастся настолько запоганить работу системы, что дальше некуда, то она втихаря сделает маленький ребут за 10-15 сек.
Какие-то стандарты соблюдены, но в каком стандарте есть RConnectionMonitor или его аналог? Вы лезете в Symbian API.