[Shr-User] [SHR-T] ffalarms

[Łukasz Pankowski]

Jeffrey Ratcliffe <jeffrey.ratcliffe at gmail.com> 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
> Shr-User at lists.shr-project.org
> http://lists.shr-project.org/mailman/listinfo/shr-user