There is no limit i guess.. you can have any number of active objects. Just make sure there are no two requests on a single active object at that particular moment.
If there no limits on the number of active objects, how can we assign priorities to them as the enum CActive::TPriority has only few priorities defined?
A normal app never needs to care about priorities on its active objects at all.
Usually, you just put all your objects at "EPriorityStandard".
Sometimes one use EPriorityIdle for CIdles to be sure it runs last of any outstanding requests.
Some complex system might want to define some more groups of priorities, but it must be a very special app to need to have different priorities on every single one of its active objects.
Also, the priorites is just an integer, so you have 4 billion to choose between. The predefined is just a few normal ones, that is way plenty for almost all applications.
If there no limits on the number of active objects, how can we assign priorities to them as the enum CActive::TPriority has only few priorities defined?
Objects with the same priority will be ordered in the list of AOs in insertion order. The limit of AOs is the limit of available memory. Scheduler keeps the AOs as a linked list so this does not require additional memory. Of course too many (really active) AOs would slow the application down.
Scheduler keeps the AOs as a linked list so this does not require additional memory. Of course too many (really active) AOs would slow the application down.
How does creating a linked list not use any additional memory?
How does having too many AOs slow an application down? An AO is doing some processing, that processing has got to be done somewhere if you reduce the number of AOs.
So many questions about active objects. One day I'll find the time to write a proper guide for them. For now though, some answers:
Quote
A normal app never needs to care about priorities on its active objects at all.
Usually, you just put all your objects at "EPriorityStandard".
It depends how complicated your app is. Define "normal". It also depends what your active objects are for.
Generally I find that the following rules apply:
Event handler AO: should be EPriorityHigh Callback AO (not self-completing): should be EPriorityStandard Worker AO (self-completing): should be EPriorityIdle
If you need more priorities than are provided your app must be really complicated or you are doing something wrong (probably the latter!)
Quote
How does creating a linked list not use any additional memory?.
Creating the list does, adding to it doesn't.
Quote
How does having too many AOs slow an application down? An AO is doing some processing, that processing has got to be done somewhere if you reduce the number of AOs.
When a request is received the ActiveScheduler has to search through the currently active AOs to find out which RunL() to call. More active AOs = more search time, but you'd have to have a very large number of active AOs to make much of a difference!
Of course too many (really active) AOs would slow the application down.
If by "really active" you mean "using lots of CPU time" then there is another thing to bear in mind:
You should limit the execution time of each RunL() to less than 200ms. This means that you can safely run a handful of AOs in your apps main thread without making the application unresponsive. If for some reason you can't do this, you should spawn a thread to do the work.
Forum posts: 66
Forum posts: 7
Forum posts: 1246
Usually, you just put all your objects at "EPriorityStandard".
Sometimes one use EPriorityIdle for CIdles to be sure it runs last of any outstanding requests.
Some complex system might want to define some more groups of priorities, but it must be a very special app to need to have different priorities on every single one of its active objects.
Also, the priorites is just an integer, so you have 4 billion to choose between. The predefined is just a few normal ones, that is way plenty for almost all applications.
Forum posts: 683
Objects with the same priority will be ordered in the list of AOs in insertion order. The limit of AOs is the limit of available memory. Scheduler keeps the AOs as a linked list so this does not require additional memory. Of course too many (really active) AOs would slow the application down.
Forum posts: 78
How does creating a linked list not use any additional memory?
How does having too many AOs slow an application down? An AO is doing some processing, that processing has got to be done somewhere if you reduce the number of AOs.
Forum posts: 110
Usually, you just put all your objects at "EPriorityStandard".
It depends how complicated your app is. Define "normal".
It also depends what your active objects are for.
Generally I find that the following rules apply:
Event handler AO: should be EPriorityHigh
Callback AO (not self-completing): should be EPriorityStandard
Worker AO (self-completing): should be EPriorityIdle
If you need more priorities than are provided your app must be really complicated or you are doing something wrong (probably the latter!)
Creating the list does, adding to it doesn't.
When a request is received the ActiveScheduler has to search through the currently active AOs to find out which RunL() to call. More active AOs = more search time, but you'd have to have a very large number of active AOs to make much of a difference!
Forum posts: 110
If by "really active" you mean "using lots of CPU time" then there is another thing to bear in mind:
You should limit the execution time of each RunL() to less than 200ms. This means that you can safely run a handful of AOs in your apps main thread without making the application unresponsive. If for some reason you can't do this, you should spawn a thread to do the work.