This is useful to clear the queue in such a way that does not cause GC, particularly when the queue will be refilled by a similar number of items than it was previously.

Now for what I originally came here for ;)

Added a very basic threadsafe implementation of the queue, which surprisingly doesn't have too huge a performance overhead. This is dependent on my previous two PRs (prevent merge conflicts, if they're accepted), but if you want to merge this but not those two, I'll resubmit a version without those changes.

➜  queue git:(pop) ✗ go test -bench=.
PASS
BenchmarkQueueSerial     10000000          334 ns/op
BenchmarkQueueGet        50000000         29.7 ns/op
BenchmarkQueueTickTock   30000000         56.3 ns/op
BenchmarkTsQueueSerial   2000000           651 ns/op
BenchmarkTsQueueGet      10000000          204 ns/op
BenchmarkTsQueueTickTock 3000000           585 ns/op
ok      github.com/connor4312/queue 36.370s

With this change, one can iterate over the queue:

for i := 0; i < q.Length(); i++ {
    if q.Get(i).(int) != i {
        t.Errorf("index %d doesn't contain %d", i, i)
    }
}

Tests output:

$ go test -v 
=== RUN TestQueueLength
--- PASS: TestQueueLength (0.00 seconds)
=== RUN TestQueueGet
--- PASS: TestQueueGet (0.01 seconds)
=== RUN TestQueueGetOORPanic
--- PASS: TestQueueGetOORPanic (0.00 seconds)
    queue_test.go:51: got panic as expected: index out of range
    queue_test.go:65: got panic as expected: index out of range
PASS
ok      github.com/eapache/queue    0.022s

Putting this up for discussion: public package api in go should rather use errors than panics. Would it make sense to have a 2.0 release implementing this approach?

…and Clear() methods and unit tests.

Please consider the changes proposed in this PR, as I have found them to be useful extensions of queue, and would like offer them for inclusion in your code base if you find any or all of them useful/acceptable.

• Negative indexing for Get() is very useful in some cases.
• Benchmarking shows that modular math makes implementation slightly faster.
• Pop() is sometimes useful instead of separate Peek() and Remove(), and when a preceeding check for empty queue is not wanted.
• Clear() is useful for emptying the queue without provoking GC due to capacity resizing.

Probably the most common means to consume a queue is popping off the first element -- removing and returning the head -- so I added a helper method called Pop() which does just that.

Depends on my previous #6, and is partly build for #8 so that we only need to acquire a single lock for common use cases.

It's considered much more idiomatic to return errors rather than panicking if something goes wrong. It might actually be dangerous to panic here... the expectation is that if there's a possiblity for an error, an error will be returned. If consumers don't see that an error is returned, they may simply assume nil is returned on an invalid request, and applications will burn...

Unfortunately this is not a backwards-compatible change.

Some useful things have landed since last tag, time for a new release so that dep and similar will grab them? AFAICS should be tagged v1.1.0 since Remove changed api (in backwards compatible way).

Hi Here is my contribution to your code, its working good on powersystems. Tested with latest version of GO .

Thanks for the code, its working good.

What do these changes do?

Added Architecture "ppc64le"

Are there changes in behavior for the user?

No

The reason I am suggesting this change is because for many of my uses of queue, I remove an item in each iteration of a loop:

for q.Length() > 0 {
    x := q.Remove()
    ...

Only in some cases (e.g. your channels) do I find a need to do a Peek() and remove separately.

Allow caller to retrieve items from the queue by specifying the number of places from the tail. Using Get(0) and Get(-1) is equivalent to Head() and Tail() often found in other queue implementations.