02-19-2009 09:50 AM
I'd be very surprised if this really fixes anything. I can't find anything in docs about holding lock for
a request call but offhand I'd presume this would almost require NOT having the lock.
The assertion that fails in your stack trace is either not literally accurate, the stack containes a severley misleading first few methods, or a severe bug since that stack apparently started by processing messages. Often the RIM classes show
up in the debugger and while no source code is available, members are observable and you may be able
to specifically find the logic behind this assertion. Since it probably does NOT check directly for
holding the UI lock, there is probably a flag it checks but this may or ma not be discernable from the debug info.
Presumably, someone else could get to this flag without holding the ( presumably required ) lock and damage
this assertion. The reason for requiring GUI modification while holding the lock is that other things can become inconsistent and this assertion failure could reflect that.
What probably happens is your grabbing the lock changes the timing enough to prevent the specific inconsistency.
Threading problems often look like this.
Unless someone from RIM or with more in depth knowledge of RIM implementation contradicts me ( and that would be about a 50-50 thing LOL), or I have missed something very obvious, I would assume you have not fixed the problem.
Also, you almost never want synchronized "just for the heck of it" as some early jvm implementations did this
and it was slow and prone to deadlock.
02-20-2009 12:15 PM
I guess you could empirically determine if that request needs to be synchronized by
making a fast and simple test case where you repeatedly call it and then go
back and forth and see if you can get your original failure mode or one likely to
be caused by a lack of synchronization. If not, I'd be concerned that this call
does not require synchronization and your fix is not helping. Normally, unless
stated otherwise, I think of a "Request" as something that puts a message
into a que for later execution and shouldn't need the queue lock.
02-20-2009 12:31 PM
Thanks for your feedback. I didn't figure that requestForeground should require the lock-- it certainly doesn't say so in the docs, and I would have expected RIM not to overlook such a thing.
The problem has gone away completely now on both the phones where it was reported. I won't have clear confirmation that this was or was not it until I am able to construct a test case, but it does seem to coincide with the solution.