IThread Suspend Magic | developer.brewmp.com IThread Suspend Magic | developer.brewmp.com

Developer

IThread Suspend Magic

Forums:

How does Qualcomm achieve the magic trick of resuming after IThread_Suspend? Is it possible to achieve the blocking behavior without IThread?

Thanks...

Code below copied from http://www.devx.com/wireless/Article/32077?trk=DXRSS_WIFI

static void Thread1Main( SThreadCtx *pMe )
{
AECHAR wsz[ 16 ];

while( 1 )
{
pMe->n++;
WSPRINTF( wsz, sizeof( wsz ), L"t1=%d", pMe->n );
IDISPLAY_DrawText( pMe->pid, AEE_FONT_NORMAL, wsz, -1, 0, 0, NULL,
IDF_ALIGN_CENTER | IDF_ALIGN_TOP);
IDISPLAY_Update (pMe->pid);

ISHELL_Resume( pMe->pis, ITHREAD_GetResumeCBK( pMe->pit ) );
ITHREAD_Suspend( pMe->pit );
}

ITHREAD manages it because your application stack is separate from the thread stack - the thread management code is simply swapping between stack frames to acheive the suspend and resume.
One problem with allowing ITHREAD_Suspend with the main application thread is that BREW expects a synchronous response to HandleEvent - you can't yield in the middle of an event handler as it would break the way everything is supposed to work.
If you are handling something like an EVT_USER in your HandleEvent code, and you know that you are going to handle it, and understand all the implications of doing so asynchronously, then you can do something like this:
myApp_HandleEvent(...)
...
case EVT_USER:
start a thread
return TRUE;
....
and now you can do what you like while processing that event, including yielding if you need to.

ITHREAD manages it because your application stack is separate from the thread stack - the thread management code is simply swapping between stack frames to acheive the suspend and resume.
One problem with allowing ITHREAD_Suspend with the main application thread is that BREW expects a synchronous response to HandleEvent - you can't yield in the middle of an event handler as it would break the way everything is supposed to work.
If you are handling something like an EVT_USER in your HandleEvent code, and you know that you are going to handle it, and understand all the implications of doing so asynchronously, then you can do something like this:
myApp_HandleEvent(...)
...
case EVT_USER:
start a thread
return TRUE;
....
and now you can do what you like while processing that event, including yielding if you need to.