- From: Allen Wirfs-Brock <allen@wirfs-brock.com>
- Date: Wed, 8 May 2013 16:32:43 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Marcos Caceres <w3c@marcosc.com>, public-script-coord <public-script-coord@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>
On May 8, 2013, at 3:42 PM, Jonas Sicking wrote: > On Wed, May 8, 2013 at 11:46 AM, Allen Wirfs-Brock > <allen@wirfs-brock.com> wrote: >> It isn't clear to me why the AlarmManger methods need to be asynchronous. > > Because the alarms need to be persisted across system restarts which > means that they need to be saved to disk. Any disk access from the > main thread always needs to be async. Is it essential that the write completes before execution continues or can it be handles as a lazy write-behind? It would seem that as long as the "application" is still actively running added alarms could be immediately available, even if the disk save has not completed. It's only when an "application" terminates/suspend that should really be necessary to wait for these writes to complete. If the persistent backup of the alarms can be made unobservable, then alarm management could be synchronous which would be a great simplification. I can imagine you arguing that when an application is resumed, a disk access may be needed before alarms can be accessed. A way around this, would be to provide an asynchronous "open" call to the alarm manager but then for all operations upon an open alarm manager to be synchronous. Allen
Received on Wednesday, 8 May 2013 23:33:17 UTC