12-09-2009 07:34 PM
The docuemntation of Application.invokeLater() is inadequate. It mentions a "size limit" of the event queue but never defines it nor says whether it is always enforced. Hence, the contract is ambiguous.
I would really like to know:
1-Am I guaranteed that a runnable that I pass to Application.invokeLater() will eventually run if the event thread does not die?
2- What is the size limit of the event queue and is it always enfoced or only when the event thread has not been entered?
3- How is the limit enforced? Do runnables just get dropped from the back of the queue and nothing else happens?
Solved! Go to Solution.
12-09-2009 08:02 PM
I'm not the right person to answer this question, you will get better answers from other responders, but at least a couple of them won't be around till Europe's morning. So perhaps this will get you going.
1. Yes, but read 2 and 3
2. I doubt you will get this information from RIM and I'm not sure it is useful
3. the Thread that is supposedly hogging the event Thread is terminated. Log entries are written to indicate the problem. Also, though I can find no documentation that supports this, I think I have seen the OS drop Runnables when it thinks they are being added too fast rather than terminate the processing Thread. Note that there is an Event Thread, but other Threads can process with the Event Lock, so may get terminated instead of the Event Thread.
Here is a KB article about this.
Support - Process [ApplicationName] killed due to message queue overflow
Article Number: DB-00401
12-10-2009 03:01 AM
Thanks for your reply.
2. If there is a hard limit then it is part of the method contract and affects how one should use the API. Without knowing that one cannot really assert "Yes" as an answer for #1, which is basically the contract of the method.
3. Thanks for this too, but this is different. What I am worried about is the number of runnables not how long an individual runnable takes to execute.
Thanks again. Let us hope one of the responders you have in mind get to see this thread.
12-10-2009 04:29 AM
I still disagree with you about the length being a useful piece of information.
When you go to the supermarket, you can choose to go into the the 'under 10 items' queue, or the normal queue. The length of the queue is not the deciding factor here, you have to factor in the time that each person in the queue will take. So you look at how much shopping each person has and make a decision based on that.
I suspect the same is true on the Blackberry, If you are adding Runnables, as long as they are short and the Event Thread is not blocked, then the queue will not get long.
If you are ever in a situation when you exceed the capacity of the queue, then you have a problem with your code because you have blocked the Event Thread.
So the length is not the useful piece of information, it is the processing time required by the Runnables. Keep that short and you will never have a length problem. So you don't care what the length is.
If you are in a position that you want to throw things at the Event Q until you have reached capacity, then you are in danger of getting hit by external events triggering additional entries you have not considered, like Key Strokes. This is a dangerous way to use the Event Queue in my opinion.
In summary, the length is of theoretical value only, in practice it should have no effect on your application's processing.
Well that is how I see it anyway. Hopefully other people will comment too.
12-10-2009 04:57 AM
a size attribute would make the access more save, but also a lot more complicated.
is the queue full? wait for it to get empty. register a listener maybe? or check every x milliseconds?
it would be a mess.
if you adhere to some basic rules, like only adding very short and performant code to the event queue and doing the heavy processing in a separate thread, the event queue is fine.
while i encountered problems with it it was mainly due to too heavy processing or using invokeandwait on inappropriate places.
12-10-2009 05:38 AM
I agree with peter_strange's post. I have two minor corrections to add.
1. It's not a thread that is terminated when the event queue overflows, but the whole process/application which owns the event queue. Thus, it does not matter which thread holds the event lock.
2. As to the OS dropping Runnables when the event queue is full, I'm not entirely sure about that. On newer OSes some non-Runnable events are dropped, but I haven't seen any Runnables being dropped. It should be quite easy to test whether Runnables are dropped or not on v5.0.0 OS. My bet is that Runnables aren't dropped because that would violate the contract of invokeLater and invokeAndWait.
12-15-2009 06:42 PM
I tried it.
The platform throws an exception and deems the application to be not responding after you have scheduled some not-very-large number of runnables.
It is a pity that this is not documented and it is a pity that the queue is so short. Now I will have to have an event queue in my code to avoid running into this situation.