Drain the event queue between ALooper_pollAll calls. ALooper_pollAll
makes an epoll to see if there is any I/O going on the underlying
resources and is relatively a costly operation. Try to consume the
queue first and block on pollAll again if necessary.
We should stop retrying if timeout occurs and return immediately.
Change-Id: I6e9f85df2dd275fb014f90f13de4f05d776d4b7d
Reviewed-on: https://go-review.googlesource.com/8590
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
If the looper is waking up, the current timeout limit is exceeded.
There are no external APIs to query if a looper is trying to wake up
or blocking to wait for the event data. Therefore, I'm this
change and will replace the timeout with a significantly high number
that could only be exceeded if sensor fails with a fatal problem.
The goal is not to wait on ALooper_pollAll forever.
This reverts commit 1575a42f33e3354db87760bcc8c9d951e35347dd.
Change-Id: I861d81f2550c4435247a0b1d4ce141e94d1e3ec9
Reviewed-on: https://go-review.googlesource.com/8565
Reviewed-by: Burcu Dogan <jbd@google.com>
Avoid blocking forever until there are no new events in the
queue. The queue should have been fed with new events once in each t,
where t is 2 * minimum delay enabled on the queue.
Change-Id: Ie6c754816e89a93adf62d71448c6c85f167350eb
Reviewed-on: https://go-review.googlesource.com/8414
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Change-Id: I0550055b54545b75248bb76086377ebbedda7f58
Reviewed-on: https://go-review.googlesource.com/8458
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This CL contains an Android-specific Manager implementation.
On Android, we create a new ALooper for each Manager instance and
all CGO calls are proxified to an OS-thread-locked goroutine.
Change-Id: I33272cd4369d0b7850f97e840fe4bbe5aee78ec0
Reviewed-on: https://go-review.googlesource.com/8249
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Sensors package will contain APIs to read data from a wide variety
of movement, position and other physical signals.
This CL contains the initial APIs that are targeting event-based
sensors. Some of the concerns that influenced the APIs are:
- Target game developers. Latency is critical, allow output rates
up to ~10 samples per second.
- It’s rarely possible to predetermine the minimally viable sample
rate requirement of the app. - Allow users to set an upper bound rate
to avoid garbage and preserve battery life.
- Allow multiple instances of accelerometer, gyroscope, magnetometer
and altimeter sensors to be started. Optimize the share of the
underlying resources as long as it is not a bottleneck for the
sample rate.
- Prefer blocking APIs. An automatic
poll-timeout could be useful if we’re far behind the sample rate.
But, sensor initialization and waking-up significantly take longer
and there is no easy way to determine a sensor is in either one of
these states.
- Provide timestamps for each event to determine the actual rate of
the sensor data.
- Allow user to return multiple events from each call. Buffering the
events at the cost of additional latency is sometimes more
neglectable than the overhead of a function call that polls the
events one by one. Allow user to determine how many items they want
to buffer. The typical latency of a read a single event is 56 usec.
Reading 8-16 events at once has a relatively lower bound per event.
For high precision throughput, the opportunity to minimize a
function call overhead could be useful.
- Allow users to check the sensor availability on the device.
Change-Id: I9582c8f025d9f922d9635e247d60817f95bdacb9
Reviewed-on: https://go-review.googlesource.com/8174
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
