On Thu, 2007-07-05 at 18:39 +0530, ext V, Sankara Narayanan wrote: > Guys, > > You really can't depend on this if your application want to execute some > 10000 lines of code. What I told is the app will have enough time to do > some minimal work (say wanna do some cleanup which is of the order of > 100 instructions or so). The go-to-suspend time is of the order of 2.x > seconds. So, we can really do it. > > Igor, > I really do not understand what you mean by NACK (is it No ACK? If yes, > please explain) You are not expecting another app (say app2) to veto (No ACK) what your master app (app1) has decided. You only want app 2 to take care of itself so that its internal state (the part you care about) will be available for restoring, should something go bad. That, btw, is the same situation as with the OOM killer. Your assumption to do something when the system starts to go in suspended mode is dangerous and, as i said, not really safe. Instead, if you save your application state when it changes (i.e. the user opens a new tab in the browser) you will be able to restore the application state in _any_ case, not just for a failed suspend. It's cleaner, deterministic and doesn't introduce artificial dependencies on kernelspace. Keep also in mind that your numbers are probably bogus on different architectures and your solution might not work (yes, i've seen your email address but that doesn't justify the creation of arch-specific coded when it's not necessary ;-) -- Cheers, Igor Igor Stoppa <igor.stoppa@xxxxxxxxx> (Nokia Multimedia - CP - OSSO / Helsinki, Finland) _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
