How +to handle completed requests

diff -r 43e37759235e -r 51a74ef9ed63 Symbian3/SDK/Source/GUID-B67DB652-A489-55C7-A3A2-D00C43BE161E.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-B67DB652-A489-55C7-A3A2-D00C43BE161E.dita Wed Mar 31 11:11:55 2010 +0100 @@ -0,0 +1,43 @@ + + + + + +How +to handle completed requestsThis document describes how an active scheduler handles a completed +request. +

When an asynchronous service provider signals completion of a request, +the active scheduler's wait completes.

The active scheduler scans those active objects whose active request flags +are set. The active objects are checked in priority order. It invokes the RunL() function +of the first active object whose request has completed. If there are no such +active objects then the signal cannot be identified and the active scheduler +raises a panic.

The RunL() function performs whatever processing is required +to complete the request, for example retrieving the results of the service +function and displaying them. It may also:

schedule another request, +for example, in a keyboard handler, a request for the next key press.
terminate the active +scheduler by calling CActiveScheduler::Stop().

If it is possible for the RunL() function to leave, then +the active object should implement the RunError() function.

The active scheduler traps any leave occurring in the RunL() function +and calls the active object's RunError() function, passing +it the leave code. RunError() has the opportunity to do appropriate +cleanup and, when complete, should return KErrNone.

If RunError() returns anything other than KErrNone, +then the active scheduler's Error() function is called. +As the default implementation of Error() raises a panic, +then a CActiveScheduler derived class must be defined +to implement a suitable Error() function.

It may be simpler to ensure that the active objects's RunError() function always returns KErrNone.

+ \ No newline at end of file