FAQ

On Wed, Aug 19, 2015 at 6:45 AM, Nigel Tao wrote:
On Wed, Aug 19, 2015 at 9:48 AM, Burcu Dogan wrote:
- Events could be sent to the app events channel via app.Send. Due to
the high frequency nature of the sensor data, using the main app event
channel might be a bottleneck.
How high is this frequency? For example, how many accelerometer events
per second would you expect, peak?

I am also not sure what should happen if the user is not consuming the
events channel. Should it be ever growing?
It might be worth exploring the idea of adding a buffer argument to
Enable, perhaps with type []Event, although maybe a little more state
is required if you want to use it as a ringbuffer.

Then, the library's event backlog won't grow without bound. If it's a
ringbuffer, recent events will overwrite (i.e. drop) the oldest
events. You only get the N most recent events, where N is the length
of the slice.

The motion.Event doesn't actually carry the buffer. Instead, it just
says that there's sensor data available. A separate function lets the
app atomically swap buffers: the app gives the library an empty buffer
and takes the (partially or completely) full one. There are no further
motion.Events sent for that sensor type until the buffer swap, and
there is no further allocation in the steady state.
That's clever, and may well be worth it for the scenario when all of
these conditions hold:

1. sensor event frequency is very high
2. the app needs to see all the events
3. the app cannot keep up

But this seems to me to be an unusual situation. If an app requests a
high-frequency event, it should plan on being able to process it.
Worst case, it can insert its own buffering between the app events
channel and its processing of an events.

The cgo calling cost is a problem, but I suspect we can work around it
if it's significant. For example, if the frequency really is high
enough the Go side could spin on a couple of buffers, communicating
state with the C side using atomic ops, and avoid uses of cgocall on
the hot path. This would be tricky to get right and only a good use of
CPU in the high frequency case, so a standard cgo version should come
first.
Passing a zero-length buffer to Enable or to Swap means to disable the sensor.
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 5 of 19 | next ›
Discussion Overview
groupgolang-dev @
categoriesgo
postedAug 18, '15 at 11:49p
activeAug 29, '15 at 8:20p
posts19
users5
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase