2010/6/5 Thomas Gleixner <tglx@xxxxxxxxxxxxx>: > On Sat, 5 Jun 2010, Arve Hjønnevåg wrote: >> 2010/6/5 Thomas Gleixner <tglx@xxxxxxxxxxxxx>: >> > On Sat, 5 Jun 2010, Arve Hjønnevåg wrote: >> >> 2010/6/5 Thomas Gleixner <tglx@xxxxxxxxxxxxx>: >> >> > B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote: >> >> Cross app calls do not go through a central process. >> > >> > It's not about a central process, it goes through your framework, >> > which should be able to deal with it. If not, it's a design failure >> > which needs to be fixed at the place where the failure happened. >> > >> >> >> >> >> >> How can it be fixed? The user presses the back button, the framework >> >> >> determines that app A is in the foreground and send the key to app A, >> >> >> app A decides that it it does not have anything internal to go back to >> >> >> and tells the framework to switch back to the previous app. If the >> >> >> user presses the back key again, the framework does not know which app >> >> >> this key should go to until app A has finished processing the first >> >> >> key press. >> >> > >> >> > Errm, what has this to do with frozen apps? If your system is >> >> > handling input events then there are no frozen apps and even if they >> >> > are frozen your framework can unfreeze them _before_ talking to them. >> >> > >> >> > So which unfixable problem are you describing with the above example ? >> >> > >> >> >> >> You are claiming that trusted code should not have any dependencies on >> >> untrusted code. I gave you a visible example of such a dependency and >> >> want you to tell me how you can avoid this dependency. Since you are >> >> claiming that our user-space framework is fundamentally broken if it >> >> has to wait for untrusted code, I don't think it is unreasonable for >> >> you to answer this. Or do you think it is valid to communicate with >> >> untrusted code when the screen is on but not when it is off. >> > >> > It does not matter whether the screen is off or not. If you need to >> > call into that untrusted app from your trusted app and you know about >> > the might be frozen state then you can deal with it. >> > >> > So taking your example: >> > >> > Event happens and gets delivered to the framework >> > >> > framework selects A because it is in the foreground >> > >> > if (A is frozen) >> > unfreeze(A) >> > >> > deliver_event_to(A) >> > >> > It's that simple. >> > >> >> That is too simple. You also have to prevent A from being frozen while >> it is processing the event or the result would be the same as if it >> was frozen beforehand. > > The framework decides when to freeze the app in the first place (as > your framework does now when it decides to suspend) > > So it knows whether the app is frozen or not. > > So it knows damend well whether it processed the event or not. > Our user-space code is not single-threaded. So just because an app was not frozen when you checked does not mean it will remain unfrozen. We can use the same user-space wakelock api we have now to prevent freezing apps instead of preventing suspend, but we loose any advantage we get from freezing just a subset of processes this way. -- Arve Hjønnevåg -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
