Long-running -services and background objects

diff -r 4816d766a08a -r f345bda72bc4 Symbian3/PDK/Source/GUID-8BD6B29C-D905-5D2B-992A-A04AAD9ABBE3.dita --- a/Symbian3/PDK/Source/GUID-8BD6B29C-D905-5D2B-992A-A04AAD9ABBE3.dita Tue Mar 30 11:42:04 2010 +0100 +++ b/Symbian3/PDK/Source/GUID-8BD6B29C-D905-5D2B-992A-A04AAD9ABBE3.dita Tue Mar 30 11:56:28 2010 +0100 @@ -1,51 +1,51 @@ - - - - - -Long-running -services and background objectsThis document describes the use of background objects to respond -to requests for long-running services. -

System responsiveness is important. Threads must be responsive to their -users — a delay of more than a few hundred milliseconds is generally unacceptable.

This implies that all RunL() functions should -complete in a few hundred milliseconds in order to maintain system responsiveness.

In some cases, servicing a request may take longer than this. For example, -printing a document, or sending a file, may take seconds or minutes to execute, -but they should not hold up the main thread. It should also be possible to -cancel long running services.

The preferred solution is to use a background active object running in -the same thread as all other active objects

With this approach, the long running service is split into multiple chunks. -The RunL() function allows itself to run for a relatively -short period and then renews its request. This background active object tracks -its own progress through the long running task so that when RunL() is -next called, the it can continue from where it finished last time.

The background active object has a lower priority than other active objects -in the thread. The user driven event-handling active objects can cancel the -background active object by calling its Cancel() function.

The advantages of this approach are:

active objects are very -cheap to create and use very few resources.
co-operating active -objects cannot pre-empt each other; therefore, there is no need for locking -and synchronization primitives when programming with multiple active objects.
active objects can share -resources that are owned by a thread.

The active object framework allows the active-object implementation of -a long-running operation to be concealed from the API, so that the service -is presented to the user simply as an asynchronous request function together -with an associated cancel function.

In cases where an active object implementation is impossible or impractical -to program, then a background thread may be used to implement a long-running -service. This approach is not recommended for code specifically designed -for Symbian platform.

+ + + + + +Long-running +services and background objectsThis document describes the use of background objects to respond +to requests for long-running services. +

System responsiveness is important. Threads must be responsive to their +users — a delay of more than a few hundred milliseconds is generally unacceptable.

This implies that all RunL() functions should +complete in a few hundred milliseconds in order to maintain system responsiveness.

In some cases, servicing a request may take longer than this. For example, +printing a document, or sending a file, may take seconds or minutes to execute, +but they should not hold up the main thread. It should also be possible to +cancel long running services.

The preferred solution is to use a background active object running in +the same thread as all other active objects

With this approach, the long running service is split into multiple chunks. +The RunL() function allows itself to run for a relatively +short period and then renews its request. This background active object tracks +its own progress through the long running task so that when RunL() is +next called, the it can continue from where it finished last time.

The background active object has a lower priority than other active objects +in the thread. The user driven event-handling active objects can cancel the +background active object by calling its Cancel() function.

The advantages of this approach are:

active objects are very +cheap to create and use very few resources.
co-operating active +objects cannot pre-empt each other; therefore, there is no need for locking +and synchronization primitives when programming with multiple active objects.
active objects can share +resources that are owned by a thread.

The active object framework allows the active-object implementation of +a long-running operation to be concealed from the API, so that the service +is presented to the user simply as an asynchronous request function together +with an associated cancel function.

In cases where an active object implementation is impossible or impractical +to program, then a background thread may be used to implement a long-running +service. This approach is not recommended for code specifically designed +for Symbian platform.

\ No newline at end of file