[tor-dev] Is it safe for second_elapsed_callback() to be called less often?

[Michael Rogers]

Hi,

When running hidden services on Android I've found it's necessary to
hold a wake lock to keep the CPU awake. Otherwise Tor's
second_elapsed_callback() doesn't get called once per second. When the
CPU eventually wakes and the callback is called, if 100 seconds or more
have passed since the last call, second_elapsed_callback() calls
circuit_note_clock_jumped(), which marks any dirty circuits as unusable.

If I understand right, this will have the effect of breaking any
existing connections to the hidden service and making the service
unreachable until it's built new intro circuits and published a new
descriptor.

#8239, #16387 and #19522 might help to reduce the downtime by improving
our chances of reusing the same intro points, but we'd still lose the
existing circuits.

It would be nice if we could avoid this downtime without holding a
permanent wake lock, which has a big impact on battery life.

A possible workaround would be to use Android's alarm API to wake the
controller process once per minute. The controller process can acquire a
wake lock for a couple of seconds to allow second_elapsed_callback() to
be called, then release the lock until the next alarm.

However, it's pretty clear that Tor wants the callback to be called once
per second and gets nervous if that doesn't happen, so I wanted to ask
about the implications of calling the callback once or twice per minute
before pursuing this idea further. Is it in any way sane?

Another possibility would be to look into how Libevent's timers work.
Perhaps we can ensure that the timers wake the CPU on Android, so
second_elapsed_callback() and any other timer-based functions get called
without keeping the CPU permanently awake?

Thanks,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9FC527CC.asc
Type: application/pgp-keys
Size: 4660 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161201/5faa7fb6/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161201/5faa7fb6/attachment.sig>