Added TODOs.
diff --git a/TODO b/TODO
new file mode 100644
index 0000000..7eaf300
--- /dev/null
+++ b/TODO
@@ -0,0 +1,41 @@
+- The consumer code needs a much cleaner abstraction
+ In the end, it's two-phase, e.g. receive message, ack message, perhaps we make this a
+ first-class citizen in the API on the consumer side where the consumer calls:
+ Receive() and gets the sequence of the message in question (or a specific value for
+ gating/idling?) and then calls Ack/Confirm etc with the message sequence?
+
+- Wireup DSL
+- Rewrite all code test first (including diamond pattern)
+- Benchmark code (go test -bench=.) (with GOMAXPROCS=2 if env GOMAXPROCS=1)
+- Squeeze little bits of performance here and there by trying a few different things
+ e.g. pointers vs structs, padding, etc.
+- Investigate ways to utilize an int32 under the hood but have it be exposed as an int64?
+ e.g. utilizing two int32s? This would allow us to remove the atomic statements surrounding
+ i386 and ARM architecutes, but may be more effort than it's worth for our particular
+ use case...
+- Understand why "slower" consumer code is faster and more consistent when performing single-item
+ publishes
+
+- Cursors should probably all be created at the same time to keep them as close together as possible:
+ https://news.ycombinator.com/item?id=7800825
+
+
+- I need to get some help doing some low-level profiling the application to find out where
+ the bottlenecks are and determining how the Go scheduler is hindering performance, if at all.
+
+- More assertive tests on CPU ordering, e.g. claim a slot which has multiple values
+ perform a computation on the sequence in some deterministic way and store each computation
+ as one of the values. Then on the reader side assert that the struct values are correct
+ for that given sequence.
+
+- Integration suite that can exercise the Disruptor code on:
+ 1. Multiple Go runtime versions, e.g. (1.1, 1.2, 1.3, etc.) (plus point releases and the latest tip)
+ 2. Multiple CPU architectures: ARM, i386, AMD64
+ 3. Multiple operation systems: Linux, OSX, Windows, etc.
+ Ideally each of the above combinations would be an individual exercise
+
+- contributors
+- license
+- readme (Github markdown?)
+
+- Website with cool images and documentation? (e.g. GoConvey)
\ No newline at end of file
diff --git a/consumer.go b/consumer.go
index c1971c8..9d55e7c 100644
--- a/consumer.go
+++ b/consumer.go
@@ -1,5 +1,6 @@
package disruptor
+// TODO: investigate performance impact of Consume(sequence, remaining int64) (consumed int64)
type Consumer interface {
Consume(lower, upper int64)
}
diff --git a/cursor.go b/cursor.go
index 300796f..d69bedd 100644
--- a/cursor.go
+++ b/cursor.go
@@ -6,6 +6,13 @@
cpuCacheLinePadding = 7
)
+// TODO: research aligned read/write:
+// https://github.com/fmstephe/fatomic/blob/master/slice.go
+// https://groups.google.com/forum/#!topic/golang-nuts/XDfQUn4U_g8
+// https://gist.github.com/anachronistic/7495541
+// http://blog.chewxy.com/2013/12/10/pointer-tagging-in-go/
+// http://www.goinggo.net/2014/01/concurrency-goroutines-and-gomaxprocs.html
+
type Cursor struct {
sequence int64
padding [cpuCacheLinePadding]int64
diff --git a/cursor_test.go b/cursor_test.go
index 9752c85..e491a4a 100644
--- a/cursor_test.go
+++ b/cursor_test.go
@@ -39,7 +39,7 @@
}
}
-func BenchmarkCursorAsBarrier(b *testing.B) {
+func BenchmarkCursorReadAsBarrier(b *testing.B) {
var barrier Barrier = NewCursor()
iterations := int64(b.N)
