when a program's runtime is too too long....... | developer.brewmp.com when a program's runtime is too too long....... | developer.brewmp.com

Developer

when a program's runtime is too too long.......

Forums:

there is a watchdog timer in BREW. If an application spends too much time without returning to the system, the phone will reset.
If my program's runtime have to be so long, and I don't want to be reseted ,how to resolve it??

The only option is that you need to implement co-operative multitasking technique(for the current versions of BREW, I hope Qualcomm makes BREW as multitasking like Symbian).
There is article written by Radu Braniste. You can find that article
http://www.developer.com/ws/brew/article.php/1497121
regards
ruben

The only option is that you need to implement co-operative multitasking technique(for the current versions of BREW, I hope Qualcomm makes BREW as multitasking like Symbian).
There is article written by Radu Braniste. You can find that article
http://www.developer.com/ws/brew/article.php/1497121
regards
ruben

On most devices running an RTOS, a watchdog is used to check the health of a thread or a process i.e. if the process is alive and well, it has to periodically "pet" the watchdog, indicating that it isn't "hung" or "runaway". If the process or thread does not pet the watchdog, the watchdog thinks something bad has happened to the process or thread and takes action.
The REX OS has a similar function. If a BREW application takes up too much of the CPU and does not yield so that another task on the phone can be executed, the phone will be reset.
To prevent your application from triggering the watchdog timer it should give up control to the BREW system periodically.
For example take a look at the following code e.g.
app_Handle_event()
{
switch(wParam)
{
case EVT_COMMAND:
for (a large number of iterations)
{
//Do some processing
}
}

Here the “for” loop is a tight loop. It does not give up control till all the iterations are done. On the handset, when control enters app_handleEvent(), the watchdog timer starts. If control is still within app_handleEvent() when the timer times out (approximately 60 seconds) then the phone will reset.
The application should break up such processes into batches as follows(only an example):
app_Handle_event()
{
switch(wParam)
{
case EVT_COMMAND:
ISHELL_SetTimer( 200 msec);
}

Timer_CallBack_function()
{
//Do a bit of processing which will not exceed the watchdog timer
// After this processing set timer again
ISHELL_SetTimer(200 msec);

This is the method in which most applications (specifically games with animation) are developed. The value of the timer that the application sets through ISHELL_SetTimer should not be too small(around 100 msec) . This again might trigger the watchdog timer. The timer should be after (and not before) a particular block of processing is done as shown above.

On most devices running an RTOS, a watchdog is used to check the health of a thread or a process i.e. if the process is alive and well, it has to periodically "pet" the watchdog, indicating that it isn't "hung" or "runaway". If the process or thread does not pet the watchdog, the watchdog thinks something bad has happened to the process or thread and takes action.
The REX OS has a similar function. If a BREW application takes up too much of the CPU and does not yield so that another task on the phone can be executed, the phone will be reset.
To prevent your application from triggering the watchdog timer it should give up control to the BREW system periodically.
For example take a look at the following code e.g.
app_Handle_event()
{
switch(wParam)
{
case EVT_COMMAND:
for (a large number of iterations)
{
//Do some processing
}
}

Here the “for” loop is a tight loop. It does not give up control till all the iterations are done. On the handset, when control enters app_handleEvent(), the watchdog timer starts. If control is still within app_handleEvent() when the timer times out (approximately 60 seconds) then the phone will reset.
The application should break up such processes into batches as follows(only an example):
app_Handle_event()
{
switch(wParam)
{
case EVT_COMMAND:
ISHELL_SetTimer( 200 msec);
}

Timer_CallBack_function()
{
//Do a bit of processing which will not exceed the watchdog timer
// After this processing set timer again
ISHELL_SetTimer(200 msec);

This is the method in which most applications (specifically games with animation) are developed. The value of the timer that the application sets through ISHELL_SetTimer should not be too small(around 100 msec) . This again might trigger the watchdog timer. The timer should be after (and not before) a particular block of processing is done as shown above.

Thank you very much for your support, and there is some other questions :)
Can I see what was in the watchdog timer? If I can see, can I change it in the application?
Can ISHELL_SetTimer() and ISHELL_StartApplet() make the watchdog timer restart(or reset)?
when the application respond a key press(event), does the watchdog timer will restart?:p
thank you very very much!

Thank you very much for your support, and there is some other questions :)
Can I see what was in the watchdog timer? If I can see, can I change it in the application?
Can ISHELL_SetTimer() and ISHELL_StartApplet() make the watchdog timer restart(or reset)?
when the application respond a key press(event), does the watchdog timer will restart?:p
thank you very very much!

I've got a similar issue, but not really.... the emulator is saying that my app is taking too long to handle an event, but the app runs great on the handset.
I ran it for hours overnight on the Grinder at 50ms event intervals. If i submit the app as it is, would NSTL fail it just because of the warning messages from the emulator?
It seems to run even faster on the handset than on the emulator for some reason.

I've got a similar issue, but not really.... the emulator is saying that my app is taking too long to handle an event, but the app runs great on the handset.
I ran it for hours overnight on the Grinder at 50ms event intervals. If i submit the app as it is, would NSTL fail it just because of the warning messages from the emulator?
It seems to run even faster on the handset than on the emulator for some reason.

Thanks to tamoghna!:rolleyes:
I have read that before , but have no use for me. My program has no tight loops, just run step by step.Because I wanna write a lot of to files in the program, so that the runtime become so long and exceed the watchdog timer.
How can i do?
Can I see what was in the watchdog timer? If I can see, can I change it in the application?
Can ISHELL_SetTimer() and ISHELL_StartApplet() make the watchdog timer restart(or reset)?
when the application respond a key press(event), does the watchdog timer will restart?

Thanks to tamoghna!:rolleyes:
I have read that before , but have no use for me. My program has no tight loops, just run step by step.Because I wanna write a lot of to files in the program, so that the runtime become so long and exceed the watchdog timer.
How can i do?
Can I see what was in the watchdog timer? If I can see, can I change it in the application?
Can ISHELL_SetTimer() and ISHELL_StartApplet() make the watchdog timer restart(or reset)?
when the application respond a key press(event), does the watchdog timer will restart?

If it's not important to get your task done within a particular amount of time, you can use the event system instead of timer callbacks. I believe this lets BREW schedule your app's tasks, instead of you doing so.
Assuming you can break up the task into steps, write an EVT_USER command event hander for each step, and then chain them together with ISHELL_PostEvent.
Here's some code.
I'm pretty sure this will solve your problem.
--t

If it's not important to get your task done within a particular amount of time, you can use the event system instead of timer callbacks. I believe this lets BREW schedule your app's tasks, instead of you doing so.
Assuming you can break up the task into steps, write an EVT_USER command event hander for each step, and then chain them together with ISHELL_PostEvent.
Here's some code.
I'm pretty sure this will solve your problem.
--t

thank you tom for your help.
Now, I have known how to use the ISHELL_PostEvent, but I just don't know the ISHELL_PostEvent can change (reset/restart) the watchdog timer or not, can't it?
If the watchdog timer continue to count, the app will be reseted, that is what I don't wanna see.

thank you tom for your help.
Now, I have known how to use the ISHELL_PostEvent, but I just don't know the ISHELL_PostEvent can change (reset/restart) the watchdog timer or not, can't it?
If the watchdog timer continue to count, the app will be reseted, that is what I don't wanna see.

The AEE gives control to your app in four routines:
1) AEEClsCreateInstance(),
2) your AEEHANDLER event handler,
3) your PFNFREEAPPDATA callback that you provide to AEEApplet_New(), and
4) your PFNNOTIFY callback function you provide to a timer call.
There might be more, but i can't think of more at the moment.
The watchdog timer starts when it calls one of these functions, and it resets to zero when you return from any of these functions.
To explicitly answer your questions: Simply calling ISHELL_SetTimer or ISHELL_PostEvent will not reset the watchdog. Exiting from your event handler is what will reset the watchdog. So you need to exit your event handler.
Then, if you had called SetTimer, your callback will be invoked with the watchdog starting at zero. Or if you had called PostEvent, then your event handler will be called with the watchdog starting at zero.
I suggest that you just forget about the watchdog and worry about it only if it's a problem.

The AEE gives control to your app in four routines:
1) AEEClsCreateInstance(),
2) your AEEHANDLER event handler,
3) your PFNFREEAPPDATA callback that you provide to AEEApplet_New(), and
4) your PFNNOTIFY callback function you provide to a timer call.
There might be more, but i can't think of more at the moment.
The watchdog timer starts when it calls one of these functions, and it resets to zero when you return from any of these functions.
To explicitly answer your questions: Simply calling ISHELL_SetTimer or ISHELL_PostEvent will not reset the watchdog. Exiting from your event handler is what will reset the watchdog. So you need to exit your event handler.
Then, if you had called SetTimer, your callback will be invoked with the watchdog starting at zero. Or if you had called PostEvent, then your event handler will be called with the watchdog starting at zero.
I suggest that you just forget about the watchdog and worry about it only if it's a problem.

thank you very much !!;)
I know what you mean. and now the watchdog become a very big problem for me.
The follow is a example :
static boolean ExtUse_HandleEvent(IApplet * pi, AEEEvent eCode, uint16 wParam, uint32 dwParam)
{
.....................
.......................
switch (eCode)
{
case EVT_APP_START:
ExtensionCls_Send(po,ptXYOffset);
return TRUE;
case EVT_APP_STOP:
return TRUE;
case EVT_COMMAND:
displayOutput(pMe,3,"recieve post or send ");
return TURE;
default:
break;
}
return FALSE;

// the follow is in the extended DLL
static int ExtensionCls_Send(IExtensionCls * po, AEEPoint ptXYOffset)
{
..............................
........................
ISHELL_SendEvent(pMe->m_pIShell, AEECLSID_EXTUSE_APP, EVT_COMMAND, EVT_USER+101, 0);
//ISHELL_PostEvent(pMe->m_pIShell, AEECLSID_EXTUSE_APP, EVT_COMMAND, EVT_USER+101, 0);
displayOutput(pMe,3,"after post or send Event");
return SUCCESS;
}
Follow your means, after the ISHELL_SendEvent (or ISHELL_PostEvent) the watchdog timer will be reseted, wan't it?
I am very eager to know the answer, thanks a lot.:p

thank you very much !!;)
I know what you mean. and now the watchdog become a very big problem for me.
The follow is a example :
static boolean ExtUse_HandleEvent(IApplet * pi, AEEEvent eCode, uint16 wParam, uint32 dwParam)
{
.....................
.......................
switch (eCode)
{
case EVT_APP_START:
ExtensionCls_Send(po,ptXYOffset);
return TRUE;
case EVT_APP_STOP:
return TRUE;
case EVT_COMMAND:
displayOutput(pMe,3,"recieve post or send ");
return TURE;
default:
break;
}
return FALSE;

// the follow is in the extended DLL
static int ExtensionCls_Send(IExtensionCls * po, AEEPoint ptXYOffset)
{
..............................
........................
ISHELL_SendEvent(pMe->m_pIShell, AEECLSID_EXTUSE_APP, EVT_COMMAND, EVT_USER+101, 0);
//ISHELL_PostEvent(pMe->m_pIShell, AEECLSID_EXTUSE_APP, EVT_COMMAND, EVT_USER+101, 0);
displayOutput(pMe,3,"after post or send Event");
return SUCCESS;
}
Follow your means, after the ISHELL_SendEvent (or ISHELL_PostEvent) the watchdog timer will be reseted, wan't it?
I am very eager to know the answer, thanks a lot.:p

using events will probably work, but I use timers for the same effect:
#define INIT_MAX 4
static void initLoop(MyApp * pApp){
switch (pApp->initlevel) {
case 1:
// do some stuff
break;
case 2:
// do some more stuff
break;
case 3:
// do even more stuff
break;
default:
break;
}
if (pApp->initlevel < INIT_MAX) {
pApp->initlevel++;
ISHELL_SetTimer( pApp->a.m_pIShell, 1, ( PFNNOTIFY ) initLoop, pApp);
}

i think this was in one of the faqs or knowledge base at one point, but now I cant seem to find the reference.
this way you can also display your progress by calculating it from the initlevel so the users know the app hasn't crashed
-Tyndal

using events will probably work, but I use timers for the same effect:
#define INIT_MAX 4
static void initLoop(MyApp * pApp){
switch (pApp->initlevel) {
case 1:
// do some stuff
break;
case 2:
// do some more stuff
break;
case 3:
// do even more stuff
break;
default:
break;
}
if (pApp->initlevel < INIT_MAX) {
pApp->initlevel++;
ISHELL_SetTimer( pApp->a.m_pIShell, 1, ( PFNNOTIFY ) initLoop, pApp);
}

i think this was in one of the faqs or knowledge base at one point, but now I cant seem to find the reference.
this way you can also display your progress by calculating it from the initlevel so the users know the app hasn't crashed
-Tyndal

Quote:Originally posted by liyan
after the ISHELL_SendEvent (or ISHELL_PostEvent) the watchdog timer will be reseted, wan't it?No, ISHELL_SendEvent is NOT the same as ISHELL_PostEvent. I guess that is confusing.
ISHELL_SendEvent will give you troubles -- it does not return immediately so it stops you from exiting your handler. Don't use it.
Use ISHELL_PostEvent or use the timer method as suggested by Tyndal.

Quote:Originally posted by liyan
after the ISHELL_SendEvent (or ISHELL_PostEvent) the watchdog timer will be reseted, wan't it?No, ISHELL_SendEvent is NOT the same as ISHELL_PostEvent. I guess that is confusing.
ISHELL_SendEvent will give you troubles -- it does not return immediately so it stops you from exiting your handler. Don't use it.
Use ISHELL_PostEvent or use the timer method as suggested by Tyndal.

ISHELL_Sendevent is same as windows Sendmessage, it is like blocking call, your task will be finished synchronously with that call where as ISHELL_postevent is like windows postmessage is non-blocking.
regards
ruben

ISHELL_Sendevent is same as windows Sendmessage, it is like blocking call, your task will be finished synchronously with that call where as ISHELL_postevent is like windows postmessage is non-blocking.
regards
ruben

Quote:Originally posted by tyndal
this way you can also display your progress by calculating it from the initlevel so the users know the app hasn't crashed
-Tyndal
Thanks tyndal, I wanna know what's the mean of the users that you said, is the system?
Because that the ISHELL_SetTimer() won't return the control to the system, how can it reset the watchdog timer?

Quote:Originally posted by tyndal
this way you can also display your progress by calculating it from the initlevel so the users know the app hasn't crashed
-Tyndal
Thanks tyndal, I wanna know what's the mean of the users that you said, is the system?
Because that the ISHELL_SetTimer() won't return the control to the system, how can it reset the watchdog timer?

The users are the people that use the phone with your application on it... if you do a bunch of processing without showing some progress bar or something on the screen, They will probably think that the application has crashed.
The watchdog timer gets reset since the SetTimer function is non-blocking. It allows the system to do its thing (like reset the watchdog timer) before the next invocation of the loop.
Just try one of the techniques on the phone and you will see that it works.
-Tyndal

The users are the people that use the phone with your application on it... if you do a bunch of processing without showing some progress bar or something on the screen, They will probably think that the application has crashed.
The watchdog timer gets reset since the SetTimer function is non-blocking. It allows the system to do its thing (like reset the watchdog timer) before the next invocation of the loop.
Just try one of the techniques on the phone and you will see that it works.
-Tyndal

THANK YOU TOM VERY...... MUCH
I havn't explain my thought clearly, that is my fault, sorry:).
Let's see the program again:
static boolean ExtUse_HandleEvent(IApplet * pi, AEEEvent eCode, uint16 wParam, uint32 dwParam)
{
.....................
.......................
switch (eCode)
{
case EVT_APP_START:
ExtensionCls_Send(po,ptXYOffset);
return TRUE;
case EVT_APP_STOP:
return TRUE;
case EVT_COMMAND:
(B)displayOutput(pMe,3,"recieve post or send ");
(C)return TURE;
default:
break;

return FALSE;

//( be careful ) the follow is in the extended DLL
static int ExtensionCls_Send(IExtensionCls * po, AEEPoint ptXYOffset)
{
..............................
........................
(A)ISHELL_SendEvent(pMe->m_pIShell, AEECLSID_EXTUSE_APP, EVT_COMMAND, EVT_USER+101, 0);
(D)displayOutput(pMe,3,"after post or send Event");
return SUCCESS;

After (A)(SentEvent) it will to do (B) , and then (C)->(D). I promise that after (C) (return TURE;) it will return to do (D);
My gaol is to reset the watchdog timer, and I think that after (C) the app will return the control to system, and then the system will reset the watchdog. Am I right?

THANK YOU TOM VERY...... MUCH
I havn't explain my thought clearly, that is my fault, sorry:).
Let's see the program again:
static boolean ExtUse_HandleEvent(IApplet * pi, AEEEvent eCode, uint16 wParam, uint32 dwParam)
{
.....................
.......................
switch (eCode)
{
case EVT_APP_START:
ExtensionCls_Send(po,ptXYOffset);
return TRUE;
case EVT_APP_STOP:
return TRUE;
case EVT_COMMAND:
(B)displayOutput(pMe,3,"recieve post or send ");
(C)return TURE;
default:
break;

return FALSE;

//( be careful ) the follow is in the extended DLL
static int ExtensionCls_Send(IExtensionCls * po, AEEPoint ptXYOffset)
{
..............................
........................
(A)ISHELL_SendEvent(pMe->m_pIShell, AEECLSID_EXTUSE_APP, EVT_COMMAND, EVT_USER+101, 0);
(D)displayOutput(pMe,3,"after post or send Event");
return SUCCESS;

After (A)(SentEvent) it will to do (B) , and then (C)->(D). I promise that after (C) (return TURE;) it will return to do (D);
My gaol is to reset the watchdog timer, and I think that after (C) the app will return the control to system, and then the system will reset the watchdog. Am I right?

Well, i didn't think i'd find myself replying to this thread again...
I would never use ISHELL_SendEvent(). It makes the control path so convoluted. You should stick to PostEvent or the timer callbacks.
I know almost nothing about extensions, but it seems like a very bad idea to make your extension synchronize on your app like that. If your extension needs to do something both before and after your main app does something, then i'd suggest that you break it into at least two parts, so in all parts your app calls the extension, not the other way around. The main app can post events to itself or use timer callbacks to chain those parts in sequence.
But to answer your question: No, you do not return control after (C). It looks to me like you return control after the event handler's EVT_APP_START case returns TRUE at (E):
static boolean ExtUse_HandleEvent(IApplet * pi,
AEEEvent eCode, uint16 wParam, uint32 dwParam)
{
....
switch (eCode)
{
case EVT_APP_START:
ExtensionCls_Send(po,ptXYOffset);
(E) return TRUE;
case EVT_COMMAND:
(B) displayOutput(pMe,3,"recieve post or send ");
(C) return TRUE;
default:
break;
}
return FALSE;

//( be careful ) the follow is in the extended DLL
static int ExtensionCls_Send(IExtensionCls * po,
AEEPoint ptXYOffset)
{
....
(A)ISHELL_SendEvent(pMe->m_pIShell, AEECLSID_EXTUSE_APP,
EVT_COMMAND, EVT_USER+101, 0);
(D)displayOutput(pMe,3,"after post or send Event");
return SUCCESS;

Well, i didn't think i'd find myself replying to this thread again...
I would never use ISHELL_SendEvent(). It makes the control path so convoluted. You should stick to PostEvent or the timer callbacks.
I know almost nothing about extensions, but it seems like a very bad idea to make your extension synchronize on your app like that. If your extension needs to do something both before and after your main app does something, then i'd suggest that you break it into at least two parts, so in all parts your app calls the extension, not the other way around. The main app can post events to itself or use timer callbacks to chain those parts in sequence.
But to answer your question: No, you do not return control after (C). It looks to me like you return control after the event handler's EVT_APP_START case returns TRUE at (E):
static boolean ExtUse_HandleEvent(IApplet * pi,
AEEEvent eCode, uint16 wParam, uint32 dwParam)
{
....
switch (eCode)
{
case EVT_APP_START:
ExtensionCls_Send(po,ptXYOffset);
(E) return TRUE;
case EVT_COMMAND:
(B) displayOutput(pMe,3,"recieve post or send ");
(C) return TRUE;
default:
break;
}
return FALSE;

//( be careful ) the follow is in the extended DLL
static int ExtensionCls_Send(IExtensionCls * po,
AEEPoint ptXYOffset)
{
....
(A)ISHELL_SendEvent(pMe->m_pIShell, AEECLSID_EXTUSE_APP,
EVT_COMMAND, EVT_USER+101, 0);
(D)displayOutput(pMe,3,"after post or send Event");
return SUCCESS;

If you used PostEvent instead of SendEvent, I think it would return control at both (E) and (C)

If you used PostEvent instead of SendEvent, I think it would return control at both (E) and (C)

Tyndal: Yes, you're right, and the sequence would be broken into two sequential parts:
1) A, D, E
2) B, C
I'm not sure if that's what Liyan is trying to do. It looks like the desired sequence was A, B, C, D.
I really think the extension should not synchronize on the app. Using PostEvent would work, but again, i'm not sure if that's what Liyan wants to do.

Tyndal: Yes, you're right, and the sequence would be broken into two sequential parts:
1) A, D, E
2) B, C
I'm not sure if that's what Liyan is trying to do. It looks like the desired sequence was A, B, C, D.
I really think the extension should not synchronize on the app. Using PostEvent would work, but again, i'm not sure if that's what Liyan wants to do.

Quote:Originally posted by tom
Tyndal: Yes, you're right, and the sequence would be broken into two sequential parts:
1) A, D, E
2) B, C
I'm not sure if that's what Liyan is trying to do. It looks like the desired sequence was A, B, C, D.
I really think the extension should not synchronize on the app. Using PostEvent would work, but again, i'm not sure if that's what Liyan wants to do.
I want to reset watchdog timer before (D).
I do some processing befor (A), if I continue to do the processing, the time will exceed the watchdog timer, so I want to reset the watchdog timer.After (A)(SendEvent) and (C)(reset watchdog timer), I continue to do processing(D). If I use PostEvent, the sequential step is (A)->(D)->(B)->(C), so the watchdog doesn't reset until (C), but in (D),the time exceed watchdog.

Quote:Originally posted by tom
Tyndal: Yes, you're right, and the sequence would be broken into two sequential parts:
1) A, D, E
2) B, C
I'm not sure if that's what Liyan is trying to do. It looks like the desired sequence was A, B, C, D.
I really think the extension should not synchronize on the app. Using PostEvent would work, but again, i'm not sure if that's what Liyan wants to do.
I want to reset watchdog timer before (D).
I do some processing befor (A), if I continue to do the processing, the time will exceed the watchdog timer, so I want to reset the watchdog timer.After (A)(SendEvent) and (C)(reset watchdog timer), I continue to do processing(D). If I use PostEvent, the sequential step is (A)->(D)->(B)->(C), so the watchdog doesn't reset until (C), but in (D),the time exceed watchdog.

So in other words, you have a long task to perform in your extension. You are trying to split it into two parts: TaskPart1 is before (A), and TaskPart2 is after (D).
Using a timer callback:
1a) The app event handler calls extension Function1,
1a) extension Function1 performs TaskPart1,
1b) extension Function1 sets a timer with callback Function2,
1c) extension Function1 returns,
1d) The app event handler returns (watchdog is reset).
Then,
2a) Your app may or may not get another event before the timer elapses.
2b) The timer elapses and invokes extension Function2,
2c) extension Function2 performs TaskPart2,
2d) extension Function2 returns (watchdog is reset).
---------
You can also do this using PostEvent:
1a) The app event handler calls extension Function1,
1b) extension Function1 performs TaskPart1,
1c) extension Function1 returns,
1d) the same app event handler calls PostEvent,
1e) the app event handler returns (watchdog is reset).
2a) The app event handler receives command event,
2b) the app event handler calls extension Function2,
2c) extension Function2 performs TaskPart2,
2d) extension Function2 returns,
2e) the app event handler returns (watchdog is reset).
Simple.
--t

So in other words, you have a long task to perform in your extension. You are trying to split it into two parts: TaskPart1 is before (A), and TaskPart2 is after (D).
Using a timer callback:
1a) The app event handler calls extension Function1,
1a) extension Function1 performs TaskPart1,
1b) extension Function1 sets a timer with callback Function2,
1c) extension Function1 returns,
1d) The app event handler returns (watchdog is reset).
Then,
2a) Your app may or may not get another event before the timer elapses.
2b) The timer elapses and invokes extension Function2,
2c) extension Function2 performs TaskPart2,
2d) extension Function2 returns (watchdog is reset).
---------
You can also do this using PostEvent:
1a) The app event handler calls extension Function1,
1b) extension Function1 performs TaskPart1,
1c) extension Function1 returns,
1d) the same app event handler calls PostEvent,
1e) the app event handler returns (watchdog is reset).
2a) The app event handler receives command event,
2b) the app event handler calls extension Function2,
2c) extension Function2 performs TaskPart2,
2d) extension Function2 returns,
2e) the app event handler returns (watchdog is reset).
Simple.
--t

tom : I understand your method ,and your method can solve my problem completely. Thank you very much.
But if use your method, neither time callback nor PostEvent can keep my data after return control (that's when the watchdog reset). So,in part1 before PostEvent, I have to think how to protect my data that will be used in part2.
I am thinking that is there a more simple solution to tell the system that my app is alive?

tom : I understand your method ,and your method can solve my problem completely. Thank you very much.
But if use your method, neither time callback nor PostEvent can keep my data after return control (that's when the watchdog reset). So,in part1 before PostEvent, I have to think how to protect my data that will be used in part2.
I am thinking that is there a more simple solution to tell the system that my app is alive?

My understanding is that you create a data structure for your extension inside of AEEClsCreateInstance. This data structure is passed to all your extension methods. You would store your data in this structure. Both the timer callback approach and the PostEvent approach can retrieve the data this way.
There is no API for resetting the watchdog. The only technique is to return control.
There are many, many terrific programming books i could suggest to you, but while reading your message, the one that came to my mind was Jon Bentley's Programming Pearls.
Good luck with your app. :)

My understanding is that you create a data structure for your extension inside of AEEClsCreateInstance. This data structure is passed to all your extension methods. You would store your data in this structure. Both the timer callback approach and the PostEvent approach can retrieve the data this way.
There is no API for resetting the watchdog. The only technique is to return control.
There are many, many terrific programming books i could suggest to you, but while reading your message, the one that came to my mind was Jon Bentley's Programming Pearls.
Good luck with your app. :)

:o
"The only technique is to return control." that you said is what I want to know.
I decide to use ISHELL_SetTimer(). I believe it can solve my problems. The left problems is just details.
Now I am finding Jon Bentley's Programming Pearls.
Thank you very much:p

:o
"The only technique is to return control." that you said is what I want to know.
I decide to use ISHELL_SetTimer(). I believe it can solve my problems. The left problems is just details.
Now I am finding Jon Bentley's Programming Pearls.
Thank you very much:p

i'm developing a application which runs in a loop... i'm using ISHELL_PostEvent....but the app is not responding to key press when it is running....
what may be the reason...
thanks

i'm developing a application which runs in a loop... i'm using ISHELL_PostEvent....but the app is not responding to key press when it is running....
what may be the reason...
thanks

Do you mean you aren't getting EVT_KEY in your event handler?

Do you mean you aren't getting EVT_KEY in your event handler?

An important note about ISHELL_PostEvent() vs. ISHELL_SetTimer():
If you cut a big function into parts by posting events, be aware that there is no way to cancel the posted event if you need to delay it for whatever reason (a user menu was called up that shouldn't be drawn over, etc.). Also, posted events will likely get thrown away if a suspend/resume event happens right between the function posting the event and the posted event.
For this reason, ISHELL_SetTimer() may be a better idea in some instances as the timer can be cancelled and reinstated upon suspend/resume, thereby ensuring that part II of the function gets executed no matter what.

An important note about ISHELL_PostEvent() vs. ISHELL_SetTimer():
If you cut a big function into parts by posting events, be aware that there is no way to cancel the posted event if you need to delay it for whatever reason (a user menu was called up that shouldn't be drawn over, etc.). Also, posted events will likely get thrown away if a suspend/resume event happens right between the function posting the event and the posted event.
For this reason, ISHELL_SetTimer() may be a better idea in some instances as the timer can be cancelled and reinstated upon suspend/resume, thereby ensuring that part II of the function gets executed no matter what.

Good points. Nice to see you here Victor.
--t

Good points. Nice to see you here Victor.
--t

I have a thought here. Even though ISHELL_SendEvent does not return immediately, it causes entry into an event loop again, right ? Isn't it that the entry into event loop will reset the watchdog timer & on exit from it again, thereby allowing more time ?
tom wrote:No, ISHELL_SendEvent is NOT the same as ISHELL_PostEvent. I guess that is confusing.
ISHELL_SendEvent will give you troubles -- it does not return immediately so it stops you from exiting your handler. Don't use it.
Use ISHELL_PostEvent or use the timer method as suggested by Tyndal.

I have a thought here. Even though ISHELL_SendEvent does not return immediately, it causes entry into an event loop again, right ? Isn't it that the entry into event loop will reset the watchdog timer & on exit from it again, thereby allowing more time ?
tom wrote:No, ISHELL_SendEvent is NOT the same as ISHELL_PostEvent. I guess that is confusing.
ISHELL_SendEvent will give you troubles -- it does not return immediately so it stops you from exiting your handler. Don't use it.
Use ISHELL_PostEvent or use the timer method as suggested by Tyndal.

The watchdog will be reset *whenever your program does NOT have control* (is not responding to events of any kind), NOT whenever your program enters/exits an event loop.

The watchdog will be reset *whenever your program does NOT have control* (is not responding to events of any kind), NOT whenever your program enters/exits an event loop.

Yes, may be not exctly at the points of entry or exit, but around them. What I meant was, AEE will reset the timer b4 entry and after exit into/from app functions to handle runaway apps. And the watchdog timer being of singleton kind, unless the AEE (ISHELL or some other module beyond that) looks at the call stack & decides not to reset the timer my thought should hold good. Writing some code or someone who has seen the internal implementation may be able to help here.

Yes, may be not exctly at the points of entry or exit, but around them. What I meant was, AEE will reset the timer b4 entry and after exit into/from app functions to handle runaway apps. And the watchdog timer being of singleton kind, unless the AEE (ISHELL or some other module beyond that) looks at the call stack & decides not to reset the timer my thought should hold good. Writing some code or someone who has seen the internal implementation may be able to help here.