RThread().Id() and RThread.Open() Problem

[Paul.Todd]

This reminds me of my old sig
"Some people, when confronted with a problem, think 'I know, I'll use a threaded framework.' Now they have two problems."

Do it like this:

Thread A:
Create a TRequestStatus (TRS_A) as part of an active object
Call SetActive()
Create your thread (Thread B) passing in this thread's id (TID_A) and TRS_A
Do stuff until TRS_A changes from KRequestPending to something else
at this point the RunL of the AO will be called.

Thread B:
Set TRS_A to KRequestPending
Do something until you need to signal Thread A
Open a thread using id TID_A
Call RequestComplete using TRS_A - this will signal the ActiveScheduler in Thread A that a AO has been signaled and will start to process it.

[NevenS]

I followed wizard_hu and paul's example and did it as they described it (paul basically described what I did in my pseudo-code).

But I just noticed that, for some reason, the AppUi::RunL() gets called only once (but with a correct status code, let's say 1234).

The other thread (MyThread) keeps calling RequestComplete on AppUi's iStatus, but AppUi::RunL() is still called only once. I also open the handle from MyThread to AppUi only once (on startup), otherwise it crashes after I closed it and tried to reopen it again.

When App::RunL() is finished, I explicitly set iStatus to TRequestPending and call SetActive().

Man, I'm starting to get a head-ache.


Then I thought that MyThread is changing the iStatus of AppUi too fast, so that it dosen't get into the ActiveScheduler "on time" (AppUi sets iStatus=TRequestPending and MyThread calls RequestComplete(iStatus) before AppUi called SetActive()). But I'm synchronizing the access to iStatus so that's not the reason.





And sometimes, it's necessary to use threads, even on a phone (they've gotten pretty powerful to be used for just telephony).

[Paul.Todd]

In Thread B check the valie of TRS_A and it if is KRequestPending then its safe to call RequestComplete, otherwise you are going to have to defer completing the the request until the status becomes KRequestPending.

In the RunL of Thead A, set the status to KRequestPending early on and call SetActive, that will keep Thread A ticking over on your active object.

[NevenS]

Nevermind that previous post, it works now (error in synchronization of iStatus)..

[NevenS]

For some reason I have to update MyThread's the pointer to AppUi::iStatus continuously, otherwise it won't work (works only once).

void AppUi::initatejob() {
myThread = new MyThread();
myThread->startThread();
myThread->extThrId = RThread().Id();
myThread->extStatus = &iStatus;
}

void AppUi::RunL() {
// job is done, do something
...

// start a new job (yes, I want to do it in RunL())
// I have to update extStatus EVERY TIME (not only once)
myThread->extStatus = &iStatus;
SetActive();
iStatus = TRequestPending;
}



TThreadId MyThread::extThrId;
TRequestStatus* MyThread::extStatus;
void MyThread::somePeriodicFunction() {
if (*extStatus == TRequestPending) {
RThread extThr;
extThr.Open(extThrId);
extThr.RequestComplete(extStatus,1234);
}
}

[Paul.Todd]

RTFM for RThread::RequestComplete?
The value passed in is a reference to a pointer and is set to NULL on return.

[NevenS]

Ah, that was new to me. It really does say so in the documentation..

Thank you all again.