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

[teor]

> On 8 Dec. 2016, at 01:20, Michael Rogers <michael at briarproject.org> wrote:
> 
>> ...
> 
> I'll spare you a long rant about the quality of Android's documentation
> and just say that I looked into this, and in summary, an unprivileged
> process can't use native calls to schedule alarms that will wake the CPU.
> 
> (There may be a few devices where alarm timer support is enabled in the
> kernel, *and* timerfd_create() supports the relevant clocks, *and* it
> hasn't yet been patched to check the CAP_WAKE_ALARM capability like
> timer_create() does, but those devices will never be the majority.)
> 
> Unfortunately, I also found that in doze mode, which was introduced in
> Android M, alarms can't be scheduled via the Android API more frequently
> than once every nine minutes. I don't think we can realistically expect
> to refactor second_elapsed_callback() to be called once every nine
> minutes, especially if no other timers can fire during that time. So my
> original question is moot. We'll have to stick with a wake lock.
> 
> I would just like to plant the seed of a thought, though. Is it possible
> to imagine a protocol for connecting a service to Tor, such that the
> device running the service can sleep for long periods without losing
> connectivity?
> 
> This has two variants. In the easy variant, the device can wake up to
> handle network traffic. In the hard variant, the device can't wake up
> until its next alarm.
> 
> This list probably isn't the place to discuss solutions to that problem
> - I just mention it as food for thought.

Please feel free to log tickets for these issues.
We can consider them as part of our upcoming mobile device work.

T

-- 
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org
------------------------------------------------------------------------