Jeffrey Ratcliffe <[email protected]> writes: > ffalarms often rings with multiple simultaneous processes. Looking > around to see what was going on, I expected to find some sort of > at-command to queue the alarms, but the only at* executable is atd. > > So: > > a. anybody else seeing this behaviour from ffalarms?
Hi Jeffrey, I, as the author of ffalarms see it too :), but as no one complains I can live with it. The problem is that at the moment if you set multiple alarms at the same time they all schedule new alarms and due to race condition between them you end up with single alarm scheduled multiple times. The simultaneous alarm processes try to own a dbus name, so only one should play at a time (but first schedule before owning the name so here is the race). But if dbus is not yet working (which may happen during system startup) they all decide dbus is not working and start to play simultaneously resulting in a sort of deny of service in GUI of the phone. That is a bad design of course, simple dirty hack done in a limited time, but based on an idea: it better is to set more alarms than needed than none at all. > > b. how do I view the atd queue on SHR-T? List of alarms: ffalarms -l (see http://ffalarms.projects.openmoko.org/#command-line-options) or simply ls /var/spoolt/at there is no atq > > Regards > > Jeff > _______________________________________________ > Shr-User mailing list > [email protected] > http://lists.shr-project.org/mailman/listinfo/shr-user _______________________________________________ Shr-User mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-user
